Karl Scotland has an interesting post over on the Agile Practitioners Forum. He describes how and why his team moved to a Kanban system.
” The primary issue was that during Sprint planning, the development team were unable to accurately identify and estimate appropriate tasks”
I once led a team that built shrink-wrapped software using a modified version of Extreme Programming (XP). For this team, release planning played an import role in solving the problem Karl describes. The team modified the XP notion of ‘stories‘ into something they called ‘features’. We didn’t have the ‘Minimum Marketable Feature’ terminology, but that was the idea.
At release planning time, we would discuss each feature until the group seemed satisfied that they understood what was involved. We would then estimate the size of the feature, as a group. Our units were ‘Ideal Hours’ and we limited our granularity to Fibonacci Numbers (…3, 5, 8, 13, 21, 34…). Each developer had a small deck of note cards with a single Fibonacci number on each. At the same time, we would each hold up the card with our estimate. Usually, we quickly had consensus.
When our estimates didn’t agree, we would dig deeper to find out why. Sometimes the feature need to be further clarified. Occasionally, one member knew of a technical hurdle or shortcut that the others did not. Other times the feature was too big to get our heads around and we would ask the product owner if it could be broken down into smaller sub-features, that would still be valuable.
The product owner developed a sense for which features were likely to be difficult for the group to estimate. Before the planning meeting, he would often seek out members of the development team and consult with them to confirm his suspicion and seek ways to better define or perhaps divide the feature. This helped minimize the number of times the team got stuck during release planning. The result was that release planning didn’t take long, and we walked out with a plan that each person understood and believed in.
When we planned a sprint, or an iteration, as we called them. We would have a developer own each feature. That developer would do their own estimate in terms of ideal hours for them. Since the feature had already be defined well enough for the team to make a consensus estimate at release planning, individuals usually felt that they had enough information and understanding to make their own personal estimate at iteration planning time. Letting the person who was going to be responsible to deliver the feature own the estimate allowed us to better plan the iterations by taking into account things like experience level, new information that had come to light, and so forth.
Both release planning and iteration planning went smoothly and produced useful estimates. The team maintained high morale and delivered a series of releases on time, feature-complete, with verifiably high quality.