Updated: Planning Game for Agile Estimation

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing.  The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book.  There are also two links added at the end of the article.  One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

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

The Rules of Scrum: Your Product Owner refines the Product Backlog so it is ready for each Sprint Planning Meeting

The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.

To learn more about Sprint Planning Meetings, visit the Scrum Team Assessment.

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

The Rules of Scrum: I take direction for product vision and scope from my team’s Product Owner

As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team.  It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI.  One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”.  If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software.  If the Team Members choose their own scope they may do much less than is needed or much more than is required.  There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.

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

The Rules of Scrum: The Sprint Planning Meeting is Timeboxed to 2 Hours / Week of Sprint Length

Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants.  In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint.  For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours.  It is acceptable for the meeting to take less time, but not more.  A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours.  Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time.  If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.

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

The Planning Game – An Estimation Method for Agile Teams

The Planning Game [PDF] – printable reference.

Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)

Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards

Process:

  1. The team goes through all the items and chooses the one which has the lowest effort. Write the number “2″ on this card (usually in the bottom right corner).
  2. The team looks at the item with the highest value.
  3. Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20″ card. It is not permissible to select two cards.
  4. Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
  5. If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
  6. The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
  7. For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
  8. Once explanations are complete, the team members collect their cards and go back to step three.

Notes:
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes

The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.

The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.

Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.

NOTE: The Planning Game is described as Planning Poker on wikipedia.  The version described there has some minor variations from this version.

A closely related method of Agile Estimation is the Bucket System.

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

Reader Survey: Important Topics for an “Agile for Managers” Workshop

Hi Everyone,

We have started putting together a list of topics / learning objectives for a new course: “Agile for Managers”. I am interested in getting suggestions from readers on topics to include. What are the challenges you have had with managing agile teams? If you are on an agile team, what are some of the challenges you have had with management? What are the burning questions you have as a manager about deciding to use agile methods? What have been some of the critical success factors in adopting agile methods? What about pitfalls?

I will summarize feedback in a future article as well as post a proposed agenda for such a workshop. In order to “give back”, I will also make the initial draft of the course materials available under a Creative Commons license so that others can use the materials.

I look forward to hearing your thoughts!

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

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

Agile Retrospectives and the Plan of Action

Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.

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 Estimation and Pairing

I just read a recent article on PMHut called “Schedule Questions: Pair Programming and the PNR Curve“. There is much in this article that is important for agile project management… and much that should be avoided at all costs!

Continue reading

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

Time is Not Negotiable

The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting “variable” in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually “buy” more time than, say, our competitors. This has important implications which deeply challenge the PMI’s PMBoK model of project management.

Continue reading

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

Strategic Plan

Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.

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

Cancelled Iteration

Last week went totally wonko for Berteig Consulting. My planning was bad, bad, bad!

Continue reading

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

First Interation Ending

My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.

Continue reading

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

My First Challenge

Wednesday is nearly done and I’m looking at my list of tasks and cringing! I’ve only done a few out of the forty for this week. What’s going on?!

Continue reading

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