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.
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.
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
- 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).
- The team looks at the item with the highest value.
- 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.
- Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
- 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.)
- 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.
- For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
- Once explanations are complete, the team members collect their cards and go back to step three.
- 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.
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!
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.
- Prepare and estimate the project requirements using Planning Poker
- Determine the team’s Velocity
- Using the team’s burn rate and velocity calculate the budget for the Iterations
- Add any capital costs
- Using the definition of “done” add pre- and post- Iteration budgets
- 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.
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.
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.
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!
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.
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.
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.
In software development (and in many other types of projects), there is a typical non-agile approach to estimation of project size. This method starts with a high-level understanding of the work to be done, the requirements, and uses that to make an initial estimate of the project size. This estimate is often stated in units such as man-months. There is a very important piece missing here that makes this estimate completely useless… that makes it pure fantasy.
Work can often be divided up so that the smaller pieces are valuable on their own. By dividing work this way, a team can deliver value incrementally. The team can choose a short period of time called an iteration and select a small amount of work to complete in that time. This work should be valuable on its own. For example, if a team is building something, then at the end of each iteration whatever is built is usable as it is. This means that each iteration includes all the planning and design as well as construction or creation necessary to deliver a final product or result.
For example, a volunteer group may desire to attract new members. A non-agile approach would have the group plan their membership campaign completely before actually executing on it. An agile approach using iterative delivery would have the group plan a small piece of work that will attract some small number of new members, execute it, and then start a new iteration. One iteration may cover the creation of and delivery of a door-to-door flyer in a neighborhood. Another iteration may cover the design, creation and publishing of a small advertisement in a local newspaper. Each iteration includes all the steps necessary to produce a furthering of the group’s goal of attracting new members.
In a business environment, iterative delivery allows for a much faster return on investment. The following diagram compares delivering value iteratively with a non-agile project delivery where results are delivered only at the end of the project:
One can see clearly from the diagrams that the non-agile delivery of value at the end of a project is also extremely risk prone and suseptible to change. If the project is cancelled just before it delivers, then a fairly substantial amount of effort is wasted. In the agile iterative delivery situation, an endeavor can be cancelled at almost any time and it is likely that substantial value has already been delivered.
Even if the work cannot actually be delivered incrementally, it almost always can be divided in a way so that it can be inspected in stages. Either method of dividing work allows us to do the work in iterations.
Iterations are fixed and consistent units of time during which work is performed and between which planning, inspection and adjustment is done. The empowered team will decide on the length of iterations for their work. As a rule of thumb iterations should be shorter than the horizon of predictability. Generally, iterations should never be longer than one month, no matter what the endeavor.
At the end of each iteration, a demonstration of the work completed is given to the stakeholders in order to amplify learning and feedback. Between iterations, the stakeholders collaborate with the team to prioritize the remaining work and choose what will be worked on during the next iteration. During the iteration, the stakeholders need to be accessible for questions and clarifications.
Iterative and incremental delivery is used to allow for the early discovery and correction of mistakes and the incorporation of learning and feedback while at the same time delivering value early.