agile-process.org Home

Honest Plans

extremeprogramming.org
 How wide is my table? I look at my table and see it is about 6 feet wide. I then triple that to 18 feet wide so I don’t underestimate. But I know this room is only 14 feet wide. So my final estimate is 14 feet wide. Unfortunately we also estimate software projects this way. Agile processes support honest estimates by accepting and mitigating honest mistakes.
 An agile process makes honest plans based on feedback. If a mistake is made a new plan is created by accepting how far we have come and revising our plans based on the new information. There is no blame, there is no sense of failure, we have learned something we didn't know before.
extimation excersize
 Let's try a simple exercise. Estimate these three lines for me. You probably just made three estimates in inches or centimeters. Those seem like good units of measure except every different type of monitor displays those lines differently. Let's estimate them in hectopixels instead. That still doesn't help too much does it? Let me tell you the top line is 1.5 hectopixels long. Now it is easy to estimate the remaining two as 3 and 2 hectopixels.
 That was a silly exercise but it has a serious point. We estimate software development using units that seem familiar to us like hours, days, and weeks, but do we really know how long that is? Every team will produce a different amount of work in an hour. You can't multiply an hour by the number of people and compute how much will get done. People just don't add up like that on a team. At the start of our project we don't know what our units of estimation are. We learn what our units mean only after we get our first measurement of actual progress.
Some Agile projects face the problem by using a fictitious unit like story point. It makes no real difference what units we use so long as the estimates are proportionate to each other. There is nothing wrong with using units of time so long as everyone knows they can't be measured by the clock on the wall.
Velocity will be an important parameter to
our iterative planning process. We compute velocity by adding up hours, days, or story point estimates to get a single number that represents work finished this iteration. The project manager can use this to suggest how much work can be done in the next iteration or sprint. The team can commit to more or less, but it is a good number to start with. For our very first iteration we may not have a velocity. If we did some initial prototypes and measured our progress we can make a guess, but we don't know yet.
We don't break down velocity by team members because people don't scale, only teams do. Everyone contributes something different to a team effort. Assuming any one team member out of a team of 8 will be 12.5% of the capacity is just plain wrong.
Comparing velocity between two teams is also a bad idea. Any two teams will have different velocities. Consider for example a team moving as fast as possible without making mistakes. What happens when you tell them to go faster like some other team? Take an incredibly productive team that severely under estimates their work, what happens if you then decide to pay them less because some other team consistently over estimates? Don't start a competition to see who has the largest estimates, that is how my table got to be 14 feet wide.
 Product owner/customer, team members/ developers, and Scrum master/manager all work together to figure out what is feasible in the time that is available. Product owners don't get every feature, developers don't just work on interesting things, and managers don't get to tell the team it isn't doing enough. There are cost and timing trade offs to be made and getting everyone together to make them is best.
 Honest plans are more than just truthful estimations. They are about realizing that plans have an expiration date. Scrum recommends a month, Extreme Programming (XP) suggests one week. Be honest about how long a plan can remain useful and plan on creating a new plan soon.
 When asked to prioritize a group of features your customer may say they are all needed this iteration or sprint. What you have is a
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
customer who does not want to make the hard decision and is delegating to the manager. If the manager responds by saying "we will try" then he is delegating to the developers. When a customer refuses to prioritize features and drop one or a manager demands a change in estimates it may seem like that customer or manager is grabbing control. They are in fact loosing control by refusing to make a difficult decision. Pushing a decision onto another person or group isn't honest. An honest plan means you have made all the difficult decisions you are responsible for making.
 Another change is the way estimates are detailed; they aren't. You want a single estimate for each feature represented in the product backlog. Customers must weigh the different options to find the most important things to do next. You can't burden them with such issues as dependencies. Put the cost of developing that feature and that feature alone on every story.
 If building this feature lowers the cost of that feature then you have already designed some shared code. Separate technical decisions from requirements decisions by estimating each feature independently and as if that is the only feature you will build. If developing this feature still lowers that feature's estimate then lower the estimate only after this feature is working. Remember that you are creating a shopping list for people without technical backgrounds. The Paradox of Process

One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
About the Author


Copyright 2009 Don Wells all rights reserved.

Most Important FirstIterative PlanningA Project HeartbeatHonest PlansTeam EmpowermentDaily CommunicationWorking Software