We started to groom our product backlog which help up reaching our sprint goals. Today we are reaching 64% of our sprint goals. The hole team must take part in grooming but it is the product owner who is responsible for it is done. I suggest using at least 10% for grooming in each sprint for all team members at least until you can say that your backlog is DEEP.
“Shit in – shit out”
I must admit that working agile have been focusing on human interaction, trust and making the development processes work as intended. Here we are talking let’s have the specification when we need them (just-in-time principle) and than we can break the specification down, estimate and plan what the next sprint should include.
We got caught with our pants down
This way of working lead us to the situation that every sprint we were caught by surprise of unknown issues or extra work needed and sometimes we felt that we didn’t have time for making the right design decisions. We simply got introduced to late to the specification to work with it in a professional way and ended up making less qualified decisions. One of the consequences was that we didn’t make our sprint goal / sprint scope. Over a period of 6 month I investigated the amount of work that were included into the sprint after planning by the term of “this we didn’t know but this is critical for this low level story to do” and I was surprised that we included 57% to the scope on this account. It is very important to understand that this extra scope in each sprint wasn’t due to changes of the business scope but simply do to missing understanding of the business needs worked into a useful break down and a good design.
Parallel design track
Once we acknowledge this issue we came up with the idea that we could make a parallel design track to the development sprint tracks which should begin working on the user stories and non-functional requirements one sprint before the development sprint. This would give us better understanding and estimates of the user stories and tasks need to be done in the next sprint. Soon we saw that one or two persons responsible felt responsible for doing this parallel design track (the person who were most qualified to do the design and of cause also was interested in doing this work). Yes it helped a lot doing the desing work before the development sprint. We got the unexpected work in an print to go from 57% to 39% in just 3 months but still 39% was unknown or extra work NOT PLANNED!
Since the consequence of having 39% extra work in a sprint was huge because we experienced that the developers couldn’t and of cause wouldn’t really COMMIT to the scope they planned to do in the sprint because they felt that no matter what constrains they set up around the scope they were not able to stay with in those limits (most of the times) which lead to no Commitment and hereby missing one of the core thing in agile development that we are able to TRUST each other. I as a agile leader can trust each team to make their commitments each sprint getting that positive spiral of success and the company management can TRUST the agile leader present, show and perform predictability for securing business need and goals.
What to do?
We started by saying that the team must use 5-10% of their time in this sprint to groom the items for next sprint. To groom means that we re-define, break down the items that is high prioritized, we estimates and the product owner re-prioritize the always prioritized backlog. Roman uses the definition “Groom” DEEP which means Designed appropriately, Emergent, Estimated and Prioritized (http://www.romanpichler.com/blog/product-backlog/making-the-product-backlog-deep/) and keeping your back up to date DEEP’ly is to groom. In another blog I like to describe how we groom but for now lets leave this subject.
The team is responsible for grooming the user story or items to the “Detailed appropriately” level of technical design and implementation details which means that the team also must break down user stories into task with a maximum size of 1 idle developer working day (our normal break down level). The team is also responsible for estimating item (see my blog on who we estimate for more information). Any item that has been groomed reaches a level of “grooming maturity” and once the items has reached the level of Clear we set the status fo the item to “Ready for development”. Now it is only items that is ready for development that we can bring into the planning leaving the planning session to take no more than 30 minutes and most important insure that the developers is COMMITTED to reaching the planned scope (read the blog on how to plan an iteration).
We have 4 teams grooming and have done it for 7 iterations. The success rate in terms of reaching the planned scope has been over 64% for these teams (18/28). For 35% of the sprints (10/28) we must improve while 7% (2/28) of the sprints was late do to unregulated reasons (sickness).
Now I’m looking forward to what numbers 2011 will bring. We will plan with using at least 10% of our sprint to groom the backlog for the upcoming sprints, because it is the single most important event to prevent us from getting “shit in”.