Author’s caveat:
Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach. Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony. This is my other trick.
Requirements for team estimation (and planning):
- Product Owner
- The whole Development Team (i.e. everyone who will be involved in doing the work)
- Product Backlog
- Definition of “Done”
When team membership changes:
A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.
When team member allocation is adjusted:
Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.
Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.
WARNING:
The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.
Step 1 – What is our current velocity?
After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!
Step 2 – What is our current capacity?
As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:
50% Chris P. Codemuncher
50% Larry Legassifulunch
25% Beth Breaksidal
40% Gertrude Gamesthadox
40% Dana Deadlinedryver
The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:
8.5 x 50% = 4.25 days Chris P. Codemuncher
8.5 x 50% = 4.25 days Larry Legassifulunch
8.5 x 25% = 2.13 days Beth Breaksidal
8.5 x 40% = 3.4 days Gertrude Gamesthadox
8.5 x 40% = 3.4 days Dana Deadlinedryver
17.43 Total combined available days per Sprint
Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.
Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:
21 Velocity
17 Capacity
21/17 V/C
(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)
Step 3 – How much capacity do we hope to have in the next Sprint?
Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”
Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…
But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:
8.5 x 50% = 4.25 days Chris P. Codemuncher
8.5 x 50% = 4.25 days Larry Legassifulunch
8.5 x 50% = 4.25 days Beth Breaksidal
8.5 x 30% = 2.55 days Gertrude Gamesthadox
8.5 x 15% = 1.28 days Dana Deadlinedryver
16.58 Total combined ACTUAL available days in Sprint 1
16 Actual capacity (rounded-down)
21/16 Actual V/C
As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.
Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:
8.5 x 100% = 8.5 days Sally Supaspeshalis
8.5 x 100% = 8.5 days Chris P. Codemuncher
8.5 x 75% = 6.38 days Larry Legassifulunch
8.5 x 50% = 4.25 days Beth Breaksidal
8.5 x 30% = 2.55 days Gertrude Gamesthadox
8.5 x 0% = 0 days Dana Deadlinedryver
(Note: Dana is also the Scrum Master with plenty of other work to do for the team)
30.18 Total combined hoped-for available days in Sprint 1
30 Hoped-for capacity (rounded-down)
Step 4 – How much velocity do we hope to have in the next Sprint?
21 Actual Historical Velocity
16 Actual Historical Capacity
30 Hoped-For Future Capacity
x Hoped-For Future Velocity
Some simple math, loaded with assumptions:
Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity
Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375
39 Hoped-For Future Velocity
Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?
Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.
Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!
See you next time,
Travis.
Affiliated Promotions:
Please share!
