When we talk about longer-term planning in Agile world we usually focus on estimating (i.e. in Story Points), team’s velocity and a way of forecasting a timeframe by which a predefined set of backlog items can be delivered.
While the above is absolutely valid and critical, we often forget that a success of a long-term delivery also depends on how a product backlog for the is prepared and maintained.
In this post I will share a few hints that can make long-term releases less painful. All of them may seem obvious and trivial, but unfortunately way to often they are ignored or not followed in real-life.
Product Backlog is ordered
Product backlog should always be ordered. Always. It’s Product Owner’s decision how exactly the product backlog is ordered and usually there are many factors that may influence it, but the order should be well-known (transparent to the whole team) and well-communicated.
It doesn’t mean that priorities (and therefore an order of product backlog items) are fixed and can’t change. It means that at any point of time an order of backlog items should reflect current understanding of priorities.
Usually, an order of the product backlog is influenced by business value, risk, technical ability, current state of technical debt, knowledge of the team, etc.
Product Backlog Items are completed in order
We need to work on tasks in line with how product backlog is ordered. We can’t have low priority issue completed while top priority one is still to be done.
Unfortunately, it’s pretty common that as soon as a team gets blocked or stuck, instead of swarming and trying to get rid of the impediment, they basically start working on a new item which usually seems much easier and tempting.
Many teams also struggle with limiting Work In Progress which results in starting many new tasks, but actually not finishing many of them. Finishing tasks may be boring. It may require stepping out of the comfort zone to get the impediments removed. Or it may require doing tasks that are outside of our “specialty” (like software developers writing documentation). But that’s what it takes to become a true, efficient Scrum team.
MoSCoW approach
Last but not least, we should try using a MoSCoW approach to planning longer releases.
If everything is a MUST-have then any problem (like inaccurate estimates, sickness, unplanned events, new risks, etc.) may immediately result in a delay to a release.
It makes it also very difficult to re-plan if priorities or a scope of the release is to be adjusted (what should you de-scope if everything is a MUST-have?).
Having some SHOULD-haves and COULD-haves (both on release level and backlog-item level) allows for easier re-prioritization and de-scoping while still keeping agreed upon release deadlines.
MoSCoW approach support incremental delivery of products. Instead of aiming for full-blown features let’s try to build and ship them incrementally, gather feedback and adapt accordinly.
