Long working days, deadlines and team pressure can impact the quality of the software that agile teams deliver. What can we do to prevent that from happening and enable teams to improve the quality of their software? Some suggestions are to arrange for scope and deadline slack, adopt pull systems, and to make sure that people can slow down and get enough sleep.
Estimations are used by agile teams and product owners for prioritizing work and to plan releases of products. They can be done on different levels and in various ways.
Agile suggest that teams should fail-fast to enable quick learning from mistakes. Learning from failure is one approach, you can also learn early and fast from successes, by doing experimentation, or by using a plan for knowledge acquisition.
“Many team and their product owners believe that the team's unique job is to deliver more and more story points, but we consider this to be a complete misunderstanding of the relation between the team and the product owner” said Damien Thouvenin and Pierrick Revol. They ran a sprint planning game on investing time to produce stories, investigate issues, reduce technical debt, or do training.
Organization mostly do an agile transformation for a whole team, project, or organizational unit, given that agile is a team driven approach. But there are also professionals who start using agile practices individually, or who are working agile as a one person team. How can individuals adopt agile, and what kind of benefits can it give them?
The principle of “responding to change over following a plan”, is it a strength or a flexibility that can’t work in practice? For example, what about agile projects that had difficulties managing changes and customers who expect too much flexibility? Can agile not live up to its promises, or is it the way that teams and organizations have adopted agile that is causing the problems?
An exploration on how project management with Scrum and the project management process areas of the Capability Maturity Model Integration for Development are related.
When you have a large backlog with many user stories, structuring a product backlog with story maps or process maps can help to keep an overview and see the bigger picture.
In his recent blog posting “Planning Poker: Avoiding Fallacies in Effort Estimate” Hayim Makabee discusses a common problem of effort estimation called planning fallacy and why planning poker helps to avoid it.
Earlier this week Jim Bird from BIDS Trading Technologies posted a blog article about the differences between Agile and Lean approaches to planning and decision making.
Interruptions are something that every team has to deal with and, if not managed appropriately, they can potentially have a detrimental affect on their ability to deliver. In a recent post on the Agile Advice blog, Mishkin Berteig described seven options that teams could consider to deal with interruptions when using Scrum or iterative Agile approaches.
There are usually multiple things which need to be done before the start of a project. Teams usually use 'Iteration Zero' to put all necessary systems in place in order to start delivering business value in subsequent iterations. Is this the right way?
During planning poker, a product owner should explain the user stories to the development team, but he or she should not try to unduly influence the development team's estimates.
Many Agile teams use the terms Story points and Complexity points interchangeably. Agile teams believe that they are better than hours just because they are based on complexity and relative size. Mike Cohn suggested that it is wrong to use story points to depict the complexity of developing a feature, they are all about the effort.
Michael de la Maza asks the question what exactly is a Story Point? He went looking for an answer and found many: “Story points represent nebulous units of time.” or “Story point is a random measure used by Scrum teams. This is used to measure the effort required to implement a story.”