After my experience working with dozens of scrum teams in transitioning to Agile, I am thoroughly convinced that a great deal of Agile success is wrapped up in the two things that most lower functioning teams do not do well – Release Planning and Backlog Grooming.
So what is backlog grooming?
Personally, I do not like the words “backlog grooming.” To me it is merely an extension of sprint planning so forgive me when I refer to this as extended sprint planning. I think one of the things that early Scrum made a mistake on is that it expected sprint planning to happen the very first day of the sprint in what for many are LONG planning sessions. In fact, I would not be surprised if the term backlog grooming was coined so that early Agilites could save face!
In other words, let’s call this something other than sprint planning so we don’t have to admit we were not 100% right on what sprint planning should be. (Given the religious nature of Agile and Scrum I fully expect to be excommunicated and eviscerated so please feel free to comment).
Over the years I have found these sessions to be not as valuable as many shorter sessions prior to the beginning of a sprint. Instead of X hours of sprint planning the first day of the sprint, I prefer to break that down into more “bite-sized” pieces, say four, one hour sessions beginning four days prior to sprint beginning.
With shorter sessions you are more likely to complete planning, keep everyone’s attention and ask and have questions answered. Simply speaking, I have tried numerous ways to plan early and often (like voting in Chicago) it has proved to be the most effective for most teams.
These sessions should include some or all of the following activities as proposed by Angela Druckman :
• Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more StoryTime sessions)
• Break down user stories that are too big (epics)
• Improve user stories that are poorly written
• Estimate backlog items
• Add acceptance criteria
• Look deeper into the backlog to do longer-range technical planning
I would also include tasking stories and doing high-level technical design. The reason is to make sure that the product owner knows how the team expects to go about completing the story so that this lead to a proper acceptance criteria. If you have absentee or not optimally engaged product owners, I would include an understanding that the product owner formally accept the team’s proposed solution and acceptance criteria before a story can be sprint planned.
So now that you agree that extended sprint planning (backlog grooming) is the best thing since sliced bread, but how much time should this take? Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. Michael Cohn has recommended roughly 10% of current sprint time to be dedicated to future sprint planning.
If I start with 8 hours in a day as baseline, this means that 24-48 minutes every day should be expended on this or 2-4 hours per week. While this may appear to be a great amount of time, the investment can pay great dividends. For those of you not doing this just think of the number of stories that were started in a sprint, completed or nearly completed only to find out that most if not all of the work was wasted. It happens to every team more often that most would admit. This extended sprint planning mitigates the risk of wasted effort.
How do you find the time? I have used the concept of early and often and integrated the extended planning into the DNA of our scrum teams. We somehow find the 15 minutes a day for our daily standup so for many of my teams we have simply added another daily meeting attended by all team members. For 30 minutes every day we meet to “groom” the backlog.
Having a daily 30 minute meeting:
• underlines the importance of this activity
• ensures that all parties will make room in their schedule for this meeting
• keeps the backlog pristine at all times
• focuses the product owner on making sure the team has the proper priority
• helps the product owner also focus on longer term strategy
• ensures better flow for developers because communication becomes structured and not ad hoc interruptive
• ensures that stories are properly tasked
• that stories are properly designed
• that stories are appropriately sized
• increases communication between all parties
• short meeting equals laser focus (little wasted meeting time)
With all of the advantages, I would hope that the Scrum gods would see the wisdom in my approach and add the extended sprint planning meeting to the core of Scrum practices.The time is in-line with their recommendations (30 minutes per day equals a little over 6% – nicely between the recommendations of Shwaber and Cohn) and well worth the daily investment.
What are your thoughts?