When it comes to effective planning and prioritisation within a Scrum team, the question often arises: how do we navigate this complex landscape? It’s a challenge that many teams face, and I can assure you, it’s not a one-size-fits-all solution. The intricacies of planning and prioritisation hinge significantly on the specific business context and its overarching goals.
Understanding Business Goals
First and foremost, it’s essential to grasp what the business is striving to achieve. The work we undertake should flow directly from these objectives. Here’s how I approach this:
- Align Work with Business Goals: Start by identifying the key goals of the organisation. What are we aiming for? This alignment ensures that every task contributes to the broader vision.
- Communicate with Stakeholders: Regular discussions with stakeholders can provide clarity on priorities and expectations. This dialogue is crucial for understanding the value of the work we’re doing.
The Challenge of Value and Size
Once we have a clear understanding of the business goals, we need to delve into the specifics of the work itself. This is where things can get a bit tricky.
- Sizing Work Items: While I’m trying to avoid the dreaded ‘E’ word—estimation—sizing is a necessary step. Understanding the scale of tasks helps us gauge their potential return on investment (ROI).
- Assessing Value: This is often a more significant challenge. The business must have a clear grasp of what constitutes value. It’s not just about completing tasks; it’s about delivering meaningful outcomes.
Balancing Value, Risk, and Size
With an understanding of value and size, we can start to formulate a prioritisation strategy. Here’s a simplified approach that I often refer to:
- Value Minus Risk Divided by Size: This formula can serve as a rudimentary method for ordering your product backlog. It’s not perfect, but it provides a starting point for discussions.
- Keep the Backlog Manageable: One of the most critical pieces of advice I can offer is to avoid cluttering your product backlog. If you find yourself with thousands of items, it’s time to declutter. A bloated backlog is not a product backlog; it’s a dumping ground.
The Importance of a Lean Backlog
In my experience, the most effective product backlogs are concise. Ideally, they should only encompass items that are relevant for the next two to three sprints. Here’s why:
- Focus on What Matters: A smaller backlog allows the team to concentrate on high-priority items that align with business goals.
- Granularity: The further out you look, the less granular the items become. This means that as you plan for the future, you should focus on broader themes rather than minute details.
Iteration and Data-Driven Decisions
Planning and prioritisation are not static processes. They require ongoing evaluation and adjustment. Here’s how I approach this:
- Collect Data: It’s vital to gather data on how customers are interacting with your product. Are the features you’re building being used? Should you consider removing certain elements instead of adding more?
- Validate Hypotheses: Merging long-term business goals with short-term product objectives, backed by data, allows for informed decision-making. This iterative process is key to ensuring that we’re on the right track.
Conclusion
In summary, effective planning and prioritisation in a Scrum team is a multifaceted endeavour that requires a deep understanding of business goals, a clear assessment of value and risk, and a commitment to maintaining a lean backlog. By focusing on what truly matters and continuously iterating based on data, we can ensure that our efforts are aligned with the needs of the business and our customers.
If you found this discussion helpful, I encourage you to engage with me. I always welcome comments and questions, and if you’d like to chat further about Agile, Scrum, or DevOps, feel free to book a coffee with me through Naked Agility. Let’s keep the conversation going!
the question is how does the scrum team plan and prioritize work effectively let’s leave aside for a moment that the word prioritizes singular rather than plural because that always triggers me a little bit but um the how do they plan and prioritize and that’s actually it’s actually quite difficult because it depends on the business it depends on the organizer like what is the business trying to achieve the work flows from the business so you need to understand what the business is trying to achieve what are their goals where are they going and then align the work towards those goals and outcomes and how they might actually do it they might um they might do sizing right I’m trying to avoid the e word right the estimation word um they might do they might do some form of sizing right we want to figure out how big some of these things are because that’s going to impact on the ROI of the item um they need to understand well how valuable is this item which is a bigger problem because now the business needs to understand what value is right which is a whole whole bigger problem for the product owner and once you kind of understand how much how much how much value there is and you understand how how big things are you also probably want to understand how risky things how much risk is involved in this item um and with all of that information then we can start to figure out uh um like value minus risk divided by size there’s a poor man’s order of your product backlog right there’s a first order and then you could nuance it from there but the reality is that I really don’t expect people to have that many things in their product backlog the one of the most important things that folks can do to help plan and prioritize the work is not have so much crap to plan and prioritize right and if you’ve got 5,000 things in your product backlog it’s not a product backlog it’s a dumping ground right there’s there’s no 5,000 things that the product owner and the scrum team and the stakeholders can actually understand what is in there and what this thing is they would need to um remove as many of those things as possible get rid of the the the I don’t know all the stuff that’s just getting why is there so many weeds in the way to try and find the value that you need to need to deliver the best product backlogs are small um the best product backlogs are probably um two or looking two or three sprints into the future maybe a little bit more if you’re a large organization but the further out into the future you look the kind of higher level the item is therefore it’s less granular and there’s less detail i.e. less weeds right because it’s a big thing it’s a tree rather than being a plant that you can go deal with and move around and I think that that de-scaling de-escalation removing as much as possible so that they can focus they can focus on the things that they’re trying to create what is what is what is the business trying to achieve select the things that go towards that achieving that business goal and iterate right you need to be collecting data and looking at are we actually being successful one of the key key pieces to to planning and prioritization is are we even working on the right thing and how do you know if you’re working on the right thing if you have no collected no data to understand how your customers are using it what your customers want um you’re building features are they still being used by your customers should you be removing stuff from your products instead of adding it I think it all comes down to a massive of data analysis and understanding of um what it is that that you’re trying to achieve so merging those those long-term goals of the business with the short-term goals of the product and the data to back up to validate your hypothesis right thanks for watching the video if you enjoyed it please like follow and subscribe I always reply to comments and if you want to have a chat about this or anything else agile scrum or devops then please book a coffee with me through naked agility
