Why is grooming so important?

The essence of this blog
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!

Heavy impact
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?

Now I didn’t figure this out my self but got inspired by Roman Pichler once I participated in one of his classes. Roman introduced the term grooming which I had never heard about before. As we learned more and more about grooming I got convinced that this might work and it was the answer I had been waiting for to solve our problem with the predictability of our sprints. Now we introduced the role product owner which that been serviced more like the traditional role system and responsibility manner with some persons working in the mine field of the business and the developers acting often as a proxy. The role of product owners lead to changes in the responsible of who and when different people should interact with the requirements and to which extend they requirement had to be broken down into High level user stories vs. low level user stories before they are presented to the team for further break down.

Let’s Groom
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.

Grooming by the product owner

When starting team grooming we had a lot of challenges. The teams understood clearly why we had to groom but finding the right split between what level the product owner should groom vs. the team should groom is still a working issue. Until now we have come up with the solution that the product owner is responsible for our grooming sessions i general. The product owner should have done all “Detailed appropriately” from a business perspective making the user story ready for the team to work with. How the product owner gets the user stories into this state I recommend using requirement workshop where Stakeholders, developers and creative persons participates (Nothing special in an agile way of this). Once started using requirement workshops it could be interesting to look at user story mapping (http://www.agileproductdesign.com/blog/the_new_backlog.html). The product owner is also responsible for the user stories are prioritized, kept updated by the latest customers feedback and existing items are modified, re-prioritized, refined or removed from the backlog.

Grooming by the team

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).

Our success
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”.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>