As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.
In case you missed it, here is the recording of yesterday's Ask a Professional Scrum Trainer webinar with Martin Hinshelwood! Watch here: http://ow.ly/ijiM50vwEkD
[Question] Within an agile Project you have a Product Vision, Smart Goals, Sprint Goals and a Roadmap. How do you make a good Forecast? Burnup chart is to vague and not accepted, even you have 6-month experience and velocity tracking. You need that forecast to get 4 more million of budget you know you will need. On top, you need to staff another team. What kind of forecast you offer and how do consider the thrid team in your forecast?
The metrics that you are currently using will decrease predictability and increase overall dissatisfaction with the process from teams to management.
Metrics like Story Points, Burnups, and Velocity do not help predictability and indeed may allow your teams to continue delivering chunky features that are difficult to predict. The enemy of predictability is size; large [batches] PBI have a negative impact on predictability. I find Velocity and Story Points are perfectly valid for teams new to Scrum that are fairly immature. Once your team is getting in the swing of things I try to very quickly introduce flow metrics of Cycle Time, Throughput, Work Item Aging, and Work In Process. Not only do these metrics encourage backlog items to be smaller, which increases predictability, they also don’t really care about the size. You can use your Throughput, Cycle time, and WIP to provide evidence for estimates with a far greater degree of statistical certainty.
I highly recommend that you read Actionable Agile Metrics for Predictability from Daniel Vacanti. This book will show you the basis by which you can get the data you desire to increase predictability within your organisation.
The Budget cycle is a holdover from the Tayloristic ideas of the Industrial Revolution when we were dealing with more defined work that can be predicted. However, in our new world of undefined work where we need to iterate to the most right solution, there is no up-front knowledge of how long things are going to take. In the Tayloristic world, we know how long each widget is going to take to make, so we focus on the delivery of the 10k widgets and we can know very predictably when it will be done. Over the years this evolved into the budget cycle that we know today. As we moved into the knowledge working world applying those tayloristic techniques to this new form of work creates huge complexity, that then resulted in huge numbers of Project Managers, Accountants, and HR to manage it all.
However, we can predict to the dollar how much our teams are going to cost! Every year; easily!
If you have 5 people on a Scrum Team then the cost of running that team is known by your business, just ask. Take your Sprint length, usually 2 weeks, and figure out how much each Sprint costs per team; this may be different between teams. You can then be extrapolated across the number of Sprints you run in a year, for a yearly cost of each team. Let's say that you figure out that you have the people to be able to run 10 teams for 23 Sprints per year, and all your teams cost $50k per sprint. You need a budget of $11.5 million to run those teams. Each Product gets assigned one or more teams, and voila! Moving from a Team-based budget from a Project-based budget is part of that transition from a focus on Project to a focus on Product that needs to happen as your organisations move towards agility & DevOps.
The pushback you get from this transition is generally due to those deep-seated tayloristic ideas and fear of what your company is going to do with all of those Project Managers, Accountants, and HR, as well as those Managers that have to justify their headcount. Don’t surprise them, involve them. Help them understand what the new world will eventually look like, a rough transition timeline, and what other options are open to the folks that you no longer need in their current role. Have them join and form Scrum Teams to solve complex problems and some folks will embrace change and others will not; That's OK.
While there are no right answers there are some answers that are better than others. For your given situation select the most right answer and iteration to the best version of it.