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