To put all of that in numbers, adopting Scrum compared to Traditional methods usually delivers a 20% increase in speed of delivery. This can be gradually improved year on year, say 5% increases each year. When we cut out 30% of our scope from the first years’ worth of work, we are already two years ahead for a lower investment in effort. I am not saying stop trying to improve your development speed; please continue and add that to the gains to be made by reducing scope.“But our stakeholders have been promised X, Y and Z, you can’t just remove any one of them.” I hear you say. That is fine, we not going to remove those items, we are going to reduce the scope of each item, honing it in on achieving the business objective(s) it relates to. The business will still get X, Y and Z, it will meet all of its objectives; it will just be achieved with slimmer versions of X, Y and Z.
The approach to delivering business outcomes faster for less effort is not magic. It is a composition of basic agile practices, wrapped up in a feedback loop and supported with lots of collaboration. To start achieving more by delivering less, follow these steps.
- Scope what you know: google “User story mapping” to start.
- Split work into smaller pieces that are vertical slices: google “splitting user stories” to start.
- Forecast your delivery outcomes: I intend to explain this in an upcoming blog post. Briefly it is predicting when you will deliver the planned work based on what you know now.
- De-scope to fit your objectives: explained below.
- As you learn more, repeat those steps just for the changes/additions/removals.
A forecast indicating late delivery
Descope to fit your objectives
While this is titled as “descoping” it will not descope everything, some items will be deferred for later releases, some will be cut never to return, some will be split with bits done now, later and much later (aka never). Any item that is removed from the current release has reduced the scope of that release and hence will increase the speed at which we can achieve the business outcomes attached to that release.
To stand a good chance of succeeding with this approach you will need to understand the business environment and the objectives that the business (aka stakeholders) are setting out to achieve now and in the near-term. Understanding this will help to guide the splitting and descoping discussions; without this knowledge you are effectively operating blind.
The work of “descoping” should be done collaboratively with a small group that represents a cross section of those involved, such as Product Owner, experienced Tester, experienced front-end developer, experienced DevOps developer. This small group should be able to move quickly, creating a view of the work that can then be reviewed more broadly.
Together the small group will repeatedly prioritise the backlog, split up larger items and move items between different releases until the delivery forecast indicates we have a chance of success (aka we have a chance of completing the release ahead of the targeted release date).
Forecast after descoping; indicating that delivery will occur ahead of the milestone
Prioritise the backlog
To figure out what to descope, and what to spend effort splitting up we need to prioritise and order backlog. When I say prioritise the backlog I mean ruthlessly prioritise by value! Forgort MoSCoW prioritisation it is too emotional; “oh I must have that”, “we should have that”. We need to be RUTHLESS! To get you started use “above the line” prioritisation. To do this visualise the backlog, draw a very clear line, then collaborate with the group to end up with only 50% or less of the items above the line. Now draw another line above that line, and repeat. You will end up with three sets of items: Top Priority <25% of the backlog, next priority <25%, and lower priority >=50%. These sets don’t have to correlate to your releases. What these sets give you is a clear view of what is important and not so important. You can even remove those lines if you like, they have no served their purpose. The backlog should also be ordered for dependencies.
Split up larger items
Larger items often hide within them some work that is crucial, some that is nice to have, and some we don’t need to do at all. Splitting up larger items helps us to uncover the work that we can move to later releases or not do at all.
I recommend that you find the largest items in your backlog, split them up, move and/or descope those smaller pieces, then go onto the next largest items. The key to remember here is to split the work into vertical slices, it is all about finding what is valuable and what is not so valuable. If you split horizontally the value is spread across all of the split-out items and you will have wasted your time splitting it up in the first place.
Move items between different releases
Whether your work starts out as separate releases/backlogs or as one larger backlog that you cut up into separate releases; having your work in separate releases provides you with flexibility in planning and how you communicate to your stakeholders about what is going to be done when.
I recommend that you always have one more release in your backlog then you include in your published delivery forecasts. This is the lowest priority release, the YAGNI release, later, never what ever you want to call it. This dumping ground allows us to keep all of the items around, reducing tough conversations with stakeholders that are deeply attached to something that should never be built.
When you move an item from an earlier release to a later release you increase the chance of the earlier release being completed by its target date. Of course, the work has not disappeared just been deferred. With the rate of the change in most businesses deferring that item may mean it is never done; depending on your point of view that may be a win or a loss.
As your small group updates these releases and their corresponding forecasts of deliver it is important to get the whole team to review them and to share them with your stakeholders.