Many teams undergoing agile transformation adapt to stand-ups, sprint reviews and retrospectives well. The first significant challenge that teams face in their transformation is during their release planning.
Agile practices nudge teams towards understanding the bigger picture, creating a backlog of work across the release, estimating and prioritising what needs to get done.
Many teams feel more comfortable with the current state, where they build their backlogs with a lot of specific detail of how something must be built and estimates of how long a solution will take to get built. Teams find it difficult to adapt to the advice of creating backlogs for the entire release with just enough details. When they receive advice on doing estimations at a release level and work on implementation in sprints, teams grapple with how to prepare and estimate their product backlog at a higher level for the release.
Teams feel they have insufficient amount of detail to do estimation (or) that a lot of detailed analysis is needed to prepare a healthy backlog that defines how to complete work for the entire release.
Teams that stare at this scenario will find it useful to reflect on the following:
- How to make their product backlog just DEEP enough? (Detailed appropriately, Estimable, Emergent, Prioritised)? And,
- How to approach estimation at a release level
It will be well worth the team’s time to take a step back and review if their backlog defines the problem needs to be solved – than describing how something must be built .
A backlog that focuses on defining the problem and explains the constraints that must be kept in mind when designing the solution is usually detailed appropriately enough.There will be areas where constraints are not clear. A common understanding of Volatility and Uncertainty in the backlog helps decision making on priorities easier.
So, how exactly do teams start creating these kind of backlogs: User journeys are a good place to start. User journeys reveal progressively what users will see or experience. User Journeys are a separate topic by itself, so we will cover that in a separate blog.
Even as teams focus on making their product backlog DEEP, they must also strive to consciously change the way they estimate a story. Teams must estimate on the size of the problem, relative to a problem they understand comfortably – rather than the effort required to create the solution.
Estimations are not the place to determine how much effort is needed or how long it may take for a team to build the solution (yesterday’s weather or a raw velocity based planning will be more appropriate)
Teams that reflect on these two areas end up appreciating the practices espoused by agile and transform the way they build software and appreciate the emphasis of discipline in agile processes
