Now that we have some estimates which include our buffers, we have to see what can realistically get done in the release. This is the process I use:
- Figure out what individual resource loading looks like.
- Establish any dependencies.
- Try to distribute work away from the most loaded resource. (Elevate the constraint)
- Assess Risks. (I’ll discuss this in future articles)
- Discuss alternatives.
- Verify validity of estimates and adjust if necessary.
- With the new information learned from 1-6, repeat the sequence at least once.
This process should be the primary focus of your Release Planning meeting. In the following sections I will talk about each of these steps individually.
Figure out what individual resource loading looks like
Use your tools here. Most Agile tools have a way to examine individual developer loading for a Sprint and Release. In lieu of that you can use an Excel Pivot Table of your Product or Sprint Backlog to create the numbers. To do this, highlight your estimate table and click the PivotTable button on the Insert ribbon and click PivotTable. (Excel 2007) This should give you something that looks like Figure 1.
Figure 1 – Excel 2007 PivotTable Empty
From here, drag the developer into the Row Labels box and Estimate,Min and Max into the Values box. You should now have something that looks like Figure 2.
Figure 2 - Excel 2007 PivotTable Basic
You will notice that our values all say “Count” and that’s not what we are looking for, we want the sum. To change this click on each of the items in the Values box and select “Value Field Settings…” and change it to “Sum.” You should now see something like Figure 3.
Figure 3 - Excel 2007 PivotTable Resource Loading
This shows us that Joe has the most work with 3 hours, followed by Bob then Chris. While this is just an example, in step 3 we will want to try to reduce Joe’s load by attempting to shift work to Bob or Chris.
Establish any dependencies
Don’t spend too much time on this one. What you want to do is take a look at the priority order of the backlog and see if you need to make any changes due to dependencies. Obviously you won’t be able to write data to the database if the database has not yet been built. In my experience, most teams tend to do this intuitively. Just to be sure, discuss the dependencies of each item as part of the Release and Sprint Planning meetings. The goal here is to sequence items in such a way that there will not be any resource downtime during a Sprint.
Try to distribute work away from the most loaded resource
In accordance with the Theory of Constraints, we want to try to elevate a constraint by shifting some of its work to other resources. This step should be fairly obvious with regards to what to do. A word of caution here. You may find that suboptimal loading creates greater throughput than a perfectly balanced load. For example your Team Lead may require slightly less loading due to his need to guide the team. You may also find the need to overload some of your team members that tend to over-estimate items.
Due to the short time frames of most Agile projects, you may choose to do this step as an informal part of the discussion of each item. If your project requires it you may need to build a risk register. In terms of the PMBOK this is covered extensively in Chapter 11 (Third Edition) and I will cover it in more detail in later posts.
Sometimes building multiple solutions to the same problem yields better results in less time. In the book Lean Software Development, Mary and Tom Poppendieck discuss this in detail in Chapter 2/Tool 6.
If there is a need for an optimal solution to a given feature, try developing 2 or 3 solutions during a Sprint and let the user decide which one is best. Often you will find the user wants some combination of the solutions. Obviously doing this is going to add work to the schedule and as such we consider it here.
This is also the point at which the team should ALL have an understanding of the approach that will be used to build out each item. Often in this dialogue, new ideas are formed that create better solutions.
Verify validity of estimates and adjust if necessary
Give the steps above, you will need to adjust your user stories, estimates and schedule. You may have found that you can add more features to a given Sprint or that you grossly underestimated what it was going to take to get it done. Either way, you will probably need to make some adjustments here. Additionally, check the validity of the new estimates using this technique and add buffers if necessary.
With the new information learned from 1-6, repeat the sequence at least once
With your adjustments in hand, go through the process again. This time it will probably go much quicker. Follow the same steps as before but also make sure the team discusses the adjustments that were made and the associated impact.
I have found this process usually takes about 3-4 days with a typical Scrum team. (2-6 people) The first day is all about estimating with the second day being performing the steps above. The 3rd and 4th days involve backlog lockdown and team commitment. In the next post I will talk about how this process ties into section 6.5 of the Third Edition PMBOK. Until then, good luck and let me know what you think!