This week I would like to revisit Agile budgeting. In the last Auspicious Agile video blog post we discussed some approaches that can be used to budget for Agile projects. This week we will look at some nuances that are helpful to consider when budgeting for Agile projects.
First let's start with how we calculate velocity. In the last blog post I talked about a method that can be used to derive a best case, worst case and most likely case for budgeting an Agile project or initiative. The foundation is calculating velocity (velocity = distance / time). We represent distance as the amount of work to be done (points), and time as the length of the iterations (sprints). Now we can calculate our budget based on an average velocity, which is a velocity that is derived over time by looking at several sprints done by a team(s) over time. For example if we have 5 sprints of history to look at and the velocities were 25, 50, 30, 40, and 10 points the average velocity would be 31.
However, it isn't necessary to use average velocity to make budget projections. You could assume a velocity (maybe because you don't have the iteration history to calculate average velocity, or maybe because the historic data is not representative. For example in the example above one of the sprints only had 10 points. That may be because there was a holiday, or team members sick or for some other reason. So in some cases it may be desireable to make budget projections based on an assumed velocity, maybe in our previous case assuming 40 would make more sense than using the actual average velocity of 31. Of course if your team has no historical information to base velocity projections on, your team would also want to make an assumption about what the velocity might be (an approach used by the Scaled Agile Framework) and refine that number later. Maybe you start by assuming 5 points per day for a two week sprint, or 50 points per sprint as the team velocity (make sure to factor in the number of team members when you make your assumption).
Another consideration is for using the T-Shirt sizing "Price per story" method of budgeting for Agile initiatives. Some teams may not be familiar with how to T-Shirt size or use relative estimating. The key is not to focus on getting too detailed on estimates, rather the focus should be to group things in groups that are relatively of the same size. For example, if you have a coffee cup and you have a bottled water and I ask you to tell me exactly how tall each one is, you will have a very hard time doing this without an accurate measuring device (i.e. ruler). Again if there is a pile of rocks and I ask you to tell me the exact weight of each rock, it will be a difficult task (without an exact measure like a scale, and the time and ability to move and weigh every rock).
Now if instead I ask you to tell me whether the previously mentioned coffee cup of water bottle is taller, that will likely be relatively easy for you to do. In the same way if I ask you to group the pile of rocks as either small medium or large that should be relatively easy to do. So "relative" estimating by comparing things is much easier to do than estimating by coming up with exact measures. This is a key difference between traditional project / initiative budgeting and Agile budgeting. In Agile we use a relative measure that is far less time consuming, but still good enough for a budget projection. So using T-Shirt sizing takes advantage of the relative estimating approach in Agile and helps to identify a reasonable budget estimate for the work (while still maintaining flexibility / agility). For the rest of how we apply T-Shirt sizing to Agile budgeting please see the video blog in my previous post "Budgeting for Agile Projects and Initiatives".
Thanks for reading, and until next time, Stay Agile!