Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game: Adaptive Planning for Adjusted Team Capacity in Scrum

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.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Seven Options for Handling Interruptions in Scrum and Other Agile Methods

Almost three years ago we wrote a brief article about interruptions.  In that article, we described four methods of dealing with interruptions.  I would like to expand on those four methods and add three more to present a comprehensive set of options for organizations struggling with this.

Option One: Follow Scrum Strictly

The rules of Scrum are clear: if it isn’t part of the team’s work for a Sprint, then it shouldn’t be done.  From the moment the team commits to work in Sprint Planning to the end of the Sprint with the Sprint Review, the team needs to be protected from interruptions.  If an interruption is truly urgent enough to warrant the team’s attention mid-Sprint, then the Sprint can be canceled.  This is a pretty extreme result however since it invalidates the team’s previous commitment.

 

The Scrum approach is based on the basic philosophy that Scrum is a system to expose the problems and obstacles in the organization.  This is painful!  In the case of interruptions, Scrum then is metaphorically throwing them back in the face of the organization and saying “this is bad behavior!  Fix the behavior that causes so many interruptions, don’t find a way to accommodate interruptions.”

For example, many teams are faced with interruptions related to their support of the software they are creating.  In Scrum, deflecting the interruptions forces the team and the organization to examine the root causes of the support issues and fix them.  If the team is producing software with lots of defects, then that needs to change.  If the team is producing software that is hard to use, then that needs to change.  If the team is producing software without the appropriate level of user documentation, then that needs to change.  But what doesn’t change is the team breaking the safety of the Sprint defined by the rules of Scrum.

Option Two: Allocate a Portion of Time to Interruptions

Given certain conditions, the amount of interruption of a team can be “stable”. If this is the case, then the team can reasonably set aside a certain percentage of their time to handle interruptions. Determining if this is possible can be done by tracking the occurrence of interruptions and the level of effort to handle them.

 

In a team using this method, there are two ways to allocate this time: everyone on the team gives a certain amount of time each day to handling interruptions OR one or two people on the team are committed full-time for a cycle to handling interruptions. In either case, if the amount of actual time spent on interruptions is less than the amount of time available, then that difference of time must be used carefully. Generally, the best use of this extra time is to work on resolving the root causes of interruptions. For example, if one person of a team is dedicated to dealing with interruptions, and most interruptions come from in-the-field bug support requests, then that person might spend any extra time working on fixing older lower-severity defects.

The amount of time that the team is allocated to handling interruptions should never be exceeded otherwise the team’s commitments at the start of the cycle are not really commitments.

This option is by far the most common systematic approach to dealing with defects

Option Three: Visible Negotiation of Change

Another common method of handling interruptions is the “fluorescent note card” method which requires visible stakeholder negotiation around the impact of interruptions. With this method, any time a stakeholder comes to the team with an interruption request, the ScrumMaster/Coach/Process Facilitator writes the request on a bright colored note card so that it is easy to distinguish it from the other tasks the team is working on in their current cycle.   The ScrumMaster then asks the team to do a task breakdown on the card and using their normal process (whatever that is) estimates the work effort. The requesting stakeholder then has to negotiate with any other stakeholders (and in particular the Product Owner/Growth Facilitator about what work to remove from the iteration in order to make room for the new work. This process works well primarily because it makes the tradeoffs visible. It does not work so well with letting the team make and keep their commitments which can have a long-term impact on trust.

 

This approach requires a few things to be in place to be effective:

  1. A visible task board instead of electronic tools for task tracking.  The visibility makes the change much more immediate and you must have the stakeholders involved right in the same physical space.  An electronic tool makes this too abstract and can lead to some important stakeholders not being properly aware of changes.
  2. A team that is reasonably good at estimating.  By “good” I mean both accurate and fast.  If it takes the team half an hour to do an accurate estimate, then that is already a significant interruption in itself!  A team should be able to look at an interruption, break down the tasks and come up with a reasonably accurate estimate within no more than 10 minutes.  Remember that doing this is already task switching so there is going to be an additional cost to the team.
  3. Finally, and perhaps most importantly, a clear agreement must be in place among stakeholders that this approach to interruptions is allowed and that the consequence of it is that the team cannot be held accountable for their commitments!!!  I cannot stress this enough!

Option Four: Separate Team for Interruptions

This option is fairly self-explanatory and in fact is just a way of saying that you have a separate support group who deals with interruptions.  The more technically capable this group is, and the more authority they have to make changes to the code/database/etc., the more effective they will be at protecting the agile teams from interruptions.

 

In some ways, this is a good approach because it makes the cost of interruptions very visible to the business: how much does your support team cost?  If this cost is growing, then it means that the development teams are creating software that is harder and harder to support.

If you follow this approach, please ensure that you do not rotate development team members through the support team as this damages the team-building process for both the development team and the support team.

(One radical option to try as an add-on to this is to defray the cost of this support team by tying developer’s salaries to the cost of support.  To make this palatable, you might simply say to the development team that any time a support person can be laid off due to improved quality in the product/system, that person’s salary will be permanently distributed and added as a raise to the salaries of the development folks.  PS.  I’ve never seen any organization do this – it’s just a theory.)

Option Five: Extremely Short Cycles

A less common, but interesting method for handling interruptions is to have extremely short iterations. In this method, choose your iteration length to be so short that you can always start work on urgent interruptions before anyone gets impatient! This can be exhausting, but it is one of the best ways to get the team and the organization to understand the large toll that these interruptions take.

 

There is a simple way to determine how long your cycle should be based on measurement.  Choose a “normal” duration (e.g. one or two weeks) and for several cycles track how many interruptions are submitted to the team, and how urgent is the turn-around time on those interruptions.  After several cycles, the team can then adjust its cycle length so that, on average, the team is able to start and finish a cycle in a time shorter than the expected frequency of interruptions.

For example, one team I worked with found that in general, they were getting interruptions that needed to be handled within three or four days, but more urgent interruptions were rare.  They decided to use a cycle that was only two days long so that on average they would complete handling an interruption in three days.  (Interruption comes half way through a cycle and is put on the backlog at the top.  The next cycle they start and finish the interruption.  Elapsed time is three days.)

Option Six: Status Quo / Suffering

There is nothing inherently wrong with continuing with your current approach to handling interruptions.  It probably makes some people miserable, but there are also some people who really enjoy crisis and constant change.  In fact, it may be part of the culture of your organization or something that is strategically important in your particular industry.  That doesn’t mean you can’t be agile, but it may mean that you are making compromises where you are trading off team performance for some other benefit.  it is important that if you choose to continue with your status quo, that you make the trade-off transparent.  Tell everyone on your teams exactly why you are making the trade-off and what is the expected benefit of doing so.

 

Option Seven: Commitment Velocity

The most sophisticated option is based on measuring a special kind of velocity called “Commitment Velocity”.  This is a mechanism that allows both interruptions to be handled mid-cycle and for teams to make commitments that they can keep.  In the simplest terms, Commitment Velocity is the minimum historical slope of a team’s Sprint burndown.

 

For example, if a team in Sprint 1 has 240 units of effort at the start of the Sprint, but, partly due to interruptions, does not finish and then has 40 units of effort left unfinished at the end of the Sprint, then the Commitment Velocity (slope) of the team is 240 – 40 = 200.  In their next Sprint planning meeting, they would plan such that they had at most 200 unites of effort in their Sprint plan.  The team then does their second Sprint and again, partly due to interruptions, they don’t finish everything.  Perhaps this second sprint started with 195 units of effort (<200) and finished with 10 units of effort remaining.  Their new Commitment Velocity is 195 – 10 = 185.  They do a third sprint, but they finish everything.

It is tempting for the team to perhaps take an average – maybe they finished 200 units of effort in their third Sprint so they average 200, 185 and 200 leaving 195.  This is not Commitment Velocity.  By definition, an average means that the team will successfully complete all their work 50% of the time.

Instead, the team maintains its Commitment Velocity of 185 for their fourth Sprint.  By the law of large numbers and the central limit theorem, as the team uses this tool of Commitment Velocity for more and more Sprints, eventually their ability to keep their commitments, even with interruptions) will become closer and closer to 100% certain.

Selecting an Option

Ultimately, the most important thing in selecting one of these options is to do so consciously and in the spirit of learning that underlies agile methods.  Choose  an option and then stick with it long enough to truly understand if it is working for you or not.

There are some things to consider as well:

  • If you are trying to do a dramatic improvement in how your organization gets stuff done, I would recommend choosing either Option One (Follow Scrum Strictly) or Option Seven (Commitment Velocity).  Both of these are options that put pressure on the team and the organization to improve.
  • If you don’t have strong executive support for Agile, then probably Options Two (Time Allocation), Four (Separate Team) and Five (Short Cycles) are going to be your best bet at first.
  • If you do have strong executive support, but you aren’t desperate to improve your organization, you might consider Option Three (Visible Negotiation).
  • Of course, Option Six (Status Quo) is the easiest… I don’t really recommend it though!  Agility requires systematic change to encourage continuous improvement.  All the other options assist with this.
Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Calculating a Budget for an Agile Project in Six Easy Steps

A former student of mine called the other day.  He asked a good question: how do you calculate the budget for a project if you are using an agile approach to delivery.  Here is the overview of the six steps to do this.  I will follow the overview with some detailed comments.

  1. Prepare and estimate the project requirements using Planning Poker
  2. Determine the team’s Velocity
  3. Using the team’s burn rate and velocity calculate the budget for the Iterations
  4. Add any capital costs
  5. Using the definition of “done” add pre- and post- Iteration budgets
  6. Apply a drag or fudge or risk factor to the overall estimate

Prepare and estimate the project requirements using Planning Poker

The project requirements have to be listed out in some order and then estimated.  If you are using Scrum as your agile approach, you will be creating a Product Backlog.  Extreme Programming and you will be creating user stories.  OpenAgile and you will be creating Value Drivers.  Kanban and you will have a backlog of work in progress.  Regardless of the agile approach you are using, in a project context you can estimate the work using the Planning Poker game.  Once you have your list, you need to get the team of people who will be working on the list to do the estimation.  Estimation for agile methods cannot be done by someone not on the team – this is considered invalid.  It’s like asking your work buddy to estimate how much time it will take to clean your own house and then telling your kids that they have to do it in that amount of time.  In other words, it’s unfair.  Planning Poker results in scores being assigned to each item of your list.  Those scores are not yet attached to time – they simply represent the relative effort of each of the items.  To connect the scores to time, we move to the next step…

Determine the team’s Velocity

The team needs to select its cycle (sprint, iteration) length.  For software projects, this is usually one or two weeks, and more rarely three or four weeks.  In other industries it may be substantially different.  I have seen cycles as short as 12 hours (24/7 mining environment) and as long as 3 months (volunteer community organization).  Once the duration of the cycle is determined, the team can use a simple method to estimate how much work they will accomplish in a cycle.  Looking at the list of work to be done, the team starts at the top item and gradually working their way down, decide what can fit (cumulatively) into their very first cycle.  Verbally, the conversation will go something like this:

“Can we all agree that we can fit the first item into our first cycle?”

- everyone responds “Yes”

“Let’s look at the second item.  Can we do the first item AND the second item in our first cycle?”

- a little discussion about what it might take to do the second item, and then everyone responds “Yes”

“Okay.  What about adding the third item?”

- more discussion, some initial concern, and finally everyone agrees that it too can fit

“How about adding the fourth item?”

- much more concern, with one individually clearly stating “I don’t think we can add it.”

“Okay.  Let’s stop with just the first three.”

Those items chosen in this way represent a certain number of points (you add up the scores from the Planning Poker game).  The number of points that the team thinks it can do in a cycle is referred to as its “Planning Velocity” or just “Velocity”.  With the velocity, we can then do one of the most important calculations in doing a budget…

Using the team’s burn rate and velocity calculate the budget for the Iterations

The team’s velocity is a proxy for how much work the team will get done in a cycle.  However, in order to understand a budget for the overall project, we need to take that estimate of the team’s output and divide it into the total amount of work.  Our list has scores on all the items.  Sum up the scores, then divide by the velocity to give you the number of cycles of work the team will need to complete the list.  For example, if after doing Planning Poker, the sum total of all the scores on all the items is 1000, and the team’s velocity is 50, then 1000 ÷ 50 = 20… This is the time budget for the team’s work to deliver these items.    To do dollar budgeting, you also need to know the team’s burn rate: how much does it cost to run the team for a cycle.  This is usually calculated based on the fully-loaded cost of a full-time-employee and you can often get this number from someone in finance or from a manager (sometimes you can figure it out from publicly available financial data).  In general, for knowledge workers, the fully-loaded cost of a full time employee is in the range of $100000/yr to $150000/yr.  Convert that to a per-cycle, per-person cost (e.g. $120000/yr ÷ 52 weeks/year x 2 weeks/cycle = $4615/person/cycle) and then multiply by the number of people on the team (e.g. $4615 x 7 people = $32305/cycle).  Finally, multiply the per-cycle cost by the number of cycles (e.g. $32305 x 20 cycles = $646100).

This is the budget for the part of the project done in the cycles by the agile team.   But of course, there are also other costs to be accounted.

Add any capital costs

Not many projects are solely labor costs.  Equipment purchases, supplies, tools, or larger items such as infrastructure, land or vehicles may all be required for your project.  Most agile methods do not provide specific guidance on how to account for these items since agile methods stem from software development where these costs tend to be minimal relative to labor costs.  However, as a Project Manager making a budget estimate, you need to check with the team (after the Planning Poker game) to determine if they know of any large purchases required for the completion of the project.  Be clear to them what you mean by “large” – in an agile environment, this is anything that has a cost similar to or more than the labor cost of a cycle (remember: agile projects should last at least several cycles so this is a relatively small percentage of the labor costs).  In the previous example calculation, the cost per cycle was $32305 so  you might ask them about any purchases that will be $30k or larger.  Add these to the project budget.

Using the definition of “done” add pre- and post- Iteration budgets

Every agile team is supposed to be “cross-functional” but in reality, there are limits to this.  For example, in most software project environments, teams do not include full-time lawyers.  This limited cross-functionality determines what the team is capable of delivering in each cycle – anything outside the team’s expertise is usually done as either pre-work or after the iterations (cycles) are finished.  Sometimes, this work can be done concurrently with the team.  In order to understand this work, it is often valuable to draw an organization-wide value stream map for project delivery.  This map will show you the proportion of time spent for each type of work in the project.  Subtract out all the work that will be done inside the agile team (their definition of “done”) and you are left with a proportion of work that must be done outside the agile team.  Based on the proportions found in the value stream map, add an appropriate amount of budget based on the project’s cycle labor costs.

Apply a drag or fudge or risk factor to the overall estimate

And of course, to come up with a final estimate, add some amount based on risk or uncertainty (never subtract!)  Generally speaking, before this step, your project budget is going to be +/- 20%-50% depending on how much you have used this approach in the past.  If you are familiar with it and have used it on a few projects, your team will be much better at understanding their initial velocity which is the foundation for much of the remaining budget estimates.  On the other hand, if you are using this method for the first time, there is a high degree of anxiety and uncertainty around the estimation process.  Please feel free to add a buffer that you feel is appropriate.  But again, never, ever, ever remove time or money from the budget at this last step.

Please let me know if you have any comments on how you have done this – tips, tricks or techniques are always welcome in the comments.

Thanks, Mishkin.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Productivity Measures

Scott Ambler has written a couple good articles about measuring productivity with velocity.  Acceleration: An Agile Productivity Measure. and Examining Acceleration.

From what I understand, this is a measure of the effect of agile on the relative improvement over time of a team.  I would beg to differ that it is a measure of productivity.  Productivity is value delivered over time.  If team A is delivering $5/week and team B is delivering $5000/week, then knowing that team A is accelerating faster than team B isn’t terribly important, particularly if the market can’t bear to absorb $6/week of whatever team A is producing.

Measuring productivity is hard.  I would love to hear from people who have tried various means to measure productivity.  I measure productivity in our business, but I can do that because we are small and everything we do has a direct effect on the bottom line.  Does your business run with that transparency?  If not, why not?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Report average velocity and fail 50% of the time

The question of “expected velocity” and long-term planning has come up at more than one client. A recent client conversation got me thinking, however, questioning how to interpret velocity when estimating and plotting a roadmap based on a current backlog of features. Assume, for a moment, a backlog of story-pointed features, and 10 good iterations (consistent team, no odd occurrences that would affect velocity). Mathematically average velocity (well, a mean really) is a 50/50 proposition for any subsequent iteration. Some organizations don’t find this level of confidence acceptable. What velocity should be reported as expected for iteration/sprint planning and roadmap forecasting, and how should it be used?

Context

Interpreting velocity, before anything else, requires some context. An agile organization that sees estimates as hypothetical might find this article is of less use. In fact, a good question is whether estimation is even a value-added activity. For this post assume an organization that sees strong value in estimation and planning.

Culture

The biggest piece of context is to know the organizational culture. This is important in two respects, and both of these cultural factors are important because they impact how Velocity is understood within the organization.

What is Failure?

First is the meaning of failure in the organization. Is failure to deliver what was committed to by the planned date considered a failure of the team, or is it simply a fact to be understood and accounted for in future planning? Even in Agile organizations, the former is often true and a hard habit to break. If not delivering to expectations is considered failure and has negative consequences, then that means that estimation is being treated not as estimation, but as prediction and contract. Velocity is therefore a commitment, and should therefore be used conservatively.

Consistency or Speed?

The second item to know is whether consistency and predictability of delivery is of a higher strategic value than the actual rate of delivery. This is often un-stated. Usually people want fast and consistent delivery. The truth is that you can get consistent, or fast software development, or a balance between the two. Lack of trust is usually a strong motivation to encourage consistency over speed, or a history of quality problems, etc. In this case, as well, Velocity is more of a boundary than an indicator.

Emotional Loading in Estimation (or why not Low-ball?)

If estimation is seen as binding, contractual, or limiting, then additional emotions get overloaded. Trust, promise, and betrayal are words used in such organizational cultures. Distrust is usually a strong factor, especially between silos (business vs. technology, company vs. project management vs. customer, etc.). So when people are asked to give estimates, even using agile-friendly mechanisms such as story points, there is usually a process of cementing that estimate into a part of an accountability model, so estimates start to get conservative. People are then accused of low-balling, others are accused of irrational expectations… we’ve all seen this. The language clearly becomes one of contention and blame. Even the term low-balling is often an outright pejorative term for estimating too conservatively.

This doesn’t happen only in agile environments, and project managers in traditional PMBOK frameworks have long factored risk into “contingency budgets”. Interestingly, however, if a Project Manager were to factor risk into the task estimates, they’d be “low-balling capacity,” yet if they were to factor it out and layer it on top of the project work, it’s “contingency budgeting” (At least in a few experiences I’ve had). Either way, someone’s adding a factor for uncertainty, based on the need to predict conservatively or liberally or somewhere in between.

That’s the point of the article: how can Agile projects use velocity to estimate as conservatively (or liberally) as is appropriate?

An average is a 50% chance to succeed (or fail)

Velocity is not a constant. It’s a set of instantaneous values on a curve, with instances being iterations. That means that it varies, and is therefore only meaningful statistically. So how do you reasonably use velocity statistically, and improve confidence? One way is to stop delivering against “average” velocity.

A lot of coaches use average velocity over the previous N iterations. This is not helpful for all sorts of reasons, if estimation is a commitment. By definition, average (well, actually a mean, but they’re close) is a 50/50 proposition. If you report the average team velocity (assuming it’s accurate), then about half the time the team will be under and about half the time the team will be over, statistically. So basically an average is a crap shoot, when taken in any given instance. It’s can only be good in the long run. For this to work, the long-haul has to include permission to fail and a lot of trust. Teams need to be able to go miss dates but will sometimes exceed dates and it should all wash out in the end. In organizations such as I’m describing, that trust isn’t there, so. Additionally, if the language of commitment is around meeting instantaneous iteration commitments (as opposed to delivering high-quality customer value as quickly as is sustain-ably possible) then you aren’t playing the long-game, you’re playing a very short-game.

Simulate Velocity, not work

In a PMI training course I took when I was at Sun Microsystems, we were nicely informed that two point estimates of tasks are a perfect way to fail half the time, per the above logic. One point estimates are just idiotic. Three point estimates were better. We simulated with a monte-carlo algorithm and found a curve and a distribution, and then determined a confidence level yadda yadda. Well, we’re trying to avoid wasting a lot of time estimating up-front, but one way to start representing velocity properly is to do the same kind of statistical modelling done in traditional product management, only simulate velocity, not work items.

In this approach, you take the last N iterations (say 10). Determine the maximum velocity (optimistic) and the minimum velocity (pessimistic), and then the mode (the velocity value that seems to occur most frequently). Then you do monte-carlo simulation so you get a statistical pattern. Now, you actually can determine an answer based on confidence. If you want to be right with an 80% confidence, you pick a velocity where 80% of the simulated runs were successful. (Note – there are a paucity of excel templates to do this math automatically, and often they are for sale. It would be nice to have a few functions with arbitrary distributions based on min-max-mode to help this along.)

It’s not perfect, and it’s a potentially huge amount of administrative overhead. Elsewhere I’ve referenced blogs that entirely oppose any estimation at all, but if you are gong to, then working statistically with simulation is the only way to take small sample numbers meaningful.

Commitment Velocity: Low-Ball as a policy.

Another approach, one perhaps controversial, but taught by some Scrum trainers is to pick the lowest historical delivered velocity. This is a commitment-based approach, on the assumption that building trust around consistent delivery is critical to building sound relationships where product owners and teams can safely state their needs and get things done with a minimum of contractual behaviour. By taking the minimum, you force a low-ball capacity, which means you can have high-confidence of success after a few iterations. You have, likely, after a while, some spare time on your hands. Teams can then choose to pull more work in (without adjusting their commitment velocity), work on “technical debt”, improve their skills, etc. A team could raise their commitment velocity in certain inflection points in the project. A new team member is added that provides a necessary skill not previously available, and after a few iterations the team is consistently hitting a higher number, but this is a careful process to ensure that they are committing, and if they don’t make their new number, it goes down to what they got accomplished.

Indemnify teams’ learning

An arguably healthier option, if you have built enough trust, is to simply indemnify a team from failing to meet the estimate. Since you’re doing mathematics on actuals to generate an expected future number, everyone can acknowledge that past behaviour is no guarantee of future behaviour, and simply use it for capacity planning. In this case, estimation is actually estimation, not commitment or contract. The team is expected to be ahead sometimes, and behind sometimes. The upside of this is that a lot of extra time isn’t spent playing with fictional numbers. Teams are spending their efforts on delivery as quickly-yet-sustain-ably as they can, and the organization treats them as trusted professionals in this. The temptation to assume you can predict the future is seen as folly, and the estimates are used to guide overall direction, not to make outward customer commitments.

Don’t be mindless

There may be other approaches, I’m sure. The agile community is certainly not short of people who love this topic and can talk for hours on “proper” estimation. The point of this post is merely to point out some options, and ask you to look at your organizational culture, team culture, customer culture, the meaning of terms like commitment, failure, success, consistency, speed, etc. As you understand the culture, balance consistency vs. speed, trust, and other factors to choose a method of estimation that meets your goals. Don’t do estimation based on your own, internal cultural assumptions, as you may have developed or been taught techniques that are useful when and where they were taught, but may no longer be so. Or maybe they weren’t so useful then either. Regardless, this because estimation cuts at the heart of the dialogue between producer and consumer, and establishes parameters for that discussion, it’s critical that you think your choice through.

[Christian also blogs at http://www.geekinasuit.com/]

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Excellent Article about Planning Velocity

J. B. Rainsberger has written an excellent article about the usefulness of planning velocity (and the places where it is not useful as well). I highly recommend reading it, particularly if you are a manager or a project manager.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail