My project is coming to an end and we are having to extend a further couple of sprints to meet the MVP (minimum viable product). Velocity for the team has been up and down due to illness or unplanned leave. Extra business-critical stories have been added to the backlog without necessarily de-scoping anything else to make room. All this has meant that it's not been possible to meet the original timescales. Without buckets full of past experience and the ability to see into the future, it can sometimes be difficult to accurately set an end date.
Should we always include contingency in our original plans? This manages expectations better, but business-critical dates still have to be met. Adding contingency means a project may finished early in the eyes of the business, but that could just be a way of sugar coating the actual truth?
I've read about calculating the best and worst possible team velocity and taking an average of these for an accurate portrayal, as illustrated in the image below:
With this you can then track your actual velocity on the diagram to keep an accurate picture of delivery sprint by sprint.
So my main question is can Agile projects be accurately time boxed for the entire delivery, and should they be? I understand that budget has to come from somewhere and we cannot keep developing forever, but at the same time we would not choose to can a six month project because it needed a further four weeks' of funding to complete. So:
- is it a case of using project burn ups/downs to have sight of changes as early as possible?
- is it dependant on the size of the project or the experience of the team?
- is it the responsibility of the Product Owner to ensure that any new requirements displace less business critical requirements to remain on track?
- or is it a combination of the above?
Are there other things I am not considering?
As always I look forward to hearing from you and appreciate any response
4 comments
Comment by Paul Moffat posted on
It's a combination.
The first is critical... the earlier a potential problem is identified then the easier it is to resolve.
The Product Owner should be prioritising based on business need. If new stories are coming in frequently then the initial scoping was wrong. If this is the case then pausing, re-scoping then re-planning (with senior buy-in including cost) and then continuing to the new plan is the best option or you will continually be in this mode.
Contingency should always be included. In the case of story points, an MVP of 200 story points should not be your target at the beginning. Prior experience would say you should aim for 220/240 (10-20% extra) and this should be what your planning is based on. This way you have options:
* if you are delivering more story points per sprint you can finish early OR deliver more than the MVP - let the business decide what they want to do
* if you are delivering fewer story points per sprint - you have already got the contingency!
* if more stories are added - you have the contingency!
As teams become more experienced, you have the option to reduce the contingency allocated at the beginning of the next project as they become more familiar with a different way of working.
Speak with Alan de St Croix and he can expand on what I've said.
Comment by Piers posted on
Hi Paul,
Thanks for the advice, I will take it all on board and speak to Alan the next chance I get.
Comment by Richard Edwards posted on
I find a useful technique is to ensure that the target points for the MVP are plotted on the Burn-Up as well as the progress towards them. Thus, if the Product Owner allows new stories into the MVP without removing any, the new target is visible to all, and the projected velocity will take longer to reach the new height. Leave the "jump" in the target points on the graph to show when the new stories were admitted into the backlog. This follows the need for transparency, and managing in the open.
Forgive me but I don't know your project, or which definition of an MVP you are using - there is in theory only one (see Wikipedia), but in government, users/customers sometimes state the MVP is all the Must Haves - it should be the smallest release you can make that is useful and you can gain feedback on, not necessarily the same thing. The contingency should be the discretionary stories you have included in the plan for the MVP, which can be dropped. Your MoSCoW should not be 100% must haves, even for the MVP - I recommend a maximum of 60% of the effort/budget to be Must Haves. Also, the MVP should only represent as little as 40% of your budget - otherwise you have no effort built in to iterate on the learnings from your users/customers after Public Beta. You should have budget and time to continue to build on the MVP while you learn from its initial release, and add features incrementally. If your MVP grows, this budget to support learning and increments can be shrunk - though be careful to have a plan for learning and improving that is still realistic.
Comment by Piers posted on
Morning Richard,
I really like the idea about the Burn-Up and that is definitely something I will use in future projects.
My project is not technically part of the Government Digital Strategy but we are aligning to it as best we can. The project itself is a simplification and lift and shift of a current data collection process on to a new data collections platform within the Agency.
The percentages you have given do mirror what we have in the backlog so that is good.
Unfortunately the budget we have covers most of the project for the MVP but I guess that is a constraint we have to work with.
Thank you for the advice, it is appreciated
Piers