How to reduce scope
So, you have the problem that you can’t meet the deadline? You added people and circulate ideas about cutting on quality in order to meet the deadline? What to do as a product owner in this situation? Your Backlog is big and full of shiny stories, but you can’t build them all? It’s sounds a little receipish, but bare with me for a moment. Here is a genuine idea: Use a relative weight backlog! What you need:
- A set of user-stories organized as a relative weight backlog
- Stakeholders and Management
- A room and time (up to 3 hrs)
- Explanation of Value+Benefit, Storypoints and Risk
- Some techies around to answer stakeholder question
- A general estimation by the stakeholders, how much value in % they want to give up, in order to meet the deadline. It’s a estimate 😉
- A empty list of stuff to remove
What are you looking for?
1. Stories that have Zero Benefit and Zero Penalty.
These should not be in the backlog anyways. If there are no dependencies to other stories, there should be questions about how the feature landed in the backlog in the first place. If you find dependencies, see if you can resolve them. Put all the items on a list.
2. Stories with low penalty or low benefit.
These can be discussed. piece by piece. Document every decision when you start closing the stories. You got the stakeholders in a room. They can make it happen. They can remove stuff from the backlog. Add stuff to “the list” while you have the discussion. Check on the dependencies.
3. Stories with high risk.
Depending on how risk was defined by the team, choose items with a lot of risk involved. Remove carefully. Risk often is related to security/scalability etc.: discuss carefully, be nice to developers. On the other hand: There can be gems. Maybe a little value created is covered by a big technical risk.
You got your own ideas about what should be in or not? Good: After a team already created a relative weight backlog in the first place every stakeholder and developer should have the right infos already. Add stuff to “the list” The work begins!
- Check if all Stories are rightly in the list. If there is to much objection: remove it from the list, back into the backlog.
- Sum Up the Value removed. Try to stay below the value that was initially agreed on.
- Make a decision about “the list”: “If technically possible remove this stories.
Meeting ends here Now the Product Owner works through the list and makes all this sad calls to People who will not receive their feature. Sad Panda day. The team works through “the list” gives it a shot to kill the stories. There were those dependencies: you might have to write new stories. Be nice and give it an estimate. If you are not estimating … ok … you just have to be sure you are removing more than you add. The “agreement” Meeting Back to the meeting room with team, management and maybe some stakeholders. The rest of the list is presented. This is what will be removed. The Team and PO present the changes that have to be made and the consequences that arise out of this. This is what will be added to the backlog. Let people ask questions. End the meeting (everybody agreed already to what will be removed) Remarks
- Don’t mix this up with a discussion about deadlines. It’s about removing scope. Have this discussion with a smaller group. You removed stuff, come up with an idea how much time that saved. So easy then.
- Yes, you have to have a relative weight backlog. The process of estimating it in the first place speeds up the sessions about removing scope.
- Doing this is a serious effort. Prepare the sessions, make everyone aware that removing stuff from a already filled backlog requires effort in the first place.
- I would estimate 3hrs for a 60 item backlog in the first meeting, the effort for the re-planning
- If you have your qualitiy requirements in the DOD or DOR, there is a lower chance for cutting of quality (win).
- Everyone took part on the decision, lower chance for bad feedback on the big project retro.