More on this book
Community
Kindle Notes & Highlights
Agile developers essentially say: We will give you a plan based on what we know today; we will adapt the plan to meet your most critical objective; we will adapt the project and our plans as we both move forward and learn new information; we expect you to understand what you are asking for—that flexibility to adapt to changing business conditions and absolute conformance to original plans are incompatible objectives. Agile Estimating and Planning addresses each of those statements.
PMI suggests the creation of an initial order of magnitude estimate, which ranges from +75% to –25%. The next estimate to be created is the budgetary estimate, with a range of +25% to –10%, followed by the final definitive estimate, with a range of +10% to –5%.
A plan conveys expectations and describes one possibility of what may come to pass over the course of a project. A plan does not guarantee an exact set of features on an exact date at a specified cost. A plan does, however, communicate and establish a set of baseline expectations. Far too often a plan is reduced to a single date, and all of the assumptions and expectations that led to that date are forgotten.
Suppose you ask me when a project will be done. I tell you seven months but provide no explanation of how I arrived at that duration. You should be skeptical of my estimate. Without additional information you have no way of determining whether I’ve thought about the question sufficiently or whether my estimate is realistic.
Suppose, instead, that I provide you a plan that estimates completion in seven to nine months, shows what work will be completed in the first one or two months, documents key assumptions, and establishes an approach for how we’ll collaboratively measure progress. In this case you can look...
This highlight has been truncated due to consecutive passage length restrictions.
The plan, although inaccurate, was even more likely useful if we consider that it should have been updated regularly throughout the course of the project.
critical problem
Features are the unit of customer value. Planning should, therefore, be at the level of features, not activities.
second problem
looking for forgotten activities rather than
for missing features.
Work expands so as to fill the time available for its completion.
if she finishes early, her boss may accuse her of having given a padded estimate. Or her boss may expect her to finish more activities early. Why risk either of these scenarios when a little web surfing can make the activity come in on schedule instead?
Gantt chart
gives implicit permission to the developer to take up to tha...
This highlight has been truncated due to consecutive passage length restrictions.
A first advantage to using IRR is that there is no requirement to establish (or, in the worst case, guess at) an organization’s discount rate, as is necessary when calculating NPV.
You cannot usually use IRR in isolation, though, for making decisions.
Steve Tockey’s Return on Software: Maximizing the Return on Your Software Investment (2004) is a wonderful book.
Include Only Work That Adds Value to This Project
Don’t include the hour in the morning when you answer email. Yes, some of those email messages are project-related, but tasks like “answer email, 1 hour” should not be included in an iteration plan.
you need to meet with the company’s director of personnel about a new annual review process. That should not be included in the iteration plan.
Be Specific Until It’s a Habit
Once something like unit testing becomes a habit, it can be included within another task. Until then, however, making it explicit helps keep awareness of the task high.
Meetings Count (A Lot)
You should identify, estimate, and include tasks for meetings related to the project. When estimating the meeting, be sure to include the time for all participants, as we...
This highlight has been truncated due to consecutive passage length restrictions.
plan as a single nine-hour task, rather than as a separate task for each team member.
Bugs An agile team has the goal of fixing all bugs in the iteration in which they are discovered. They become able to achieve this as they become more proficient in working in short iterations, especially through relying on automated testing.
A defect found later (or not fixed during the iteration in which it was discovered) is treated the same way as a user story.
“Can you commit to delivering the features we’ve discussed?”
is not “Can you commit to delivering the tasks we’ve identified?” That is a very different question and a far weaker commitment, because it is a commitment to complete a set of tasks rather than a commitment to deliver new functionality.
most teams are successful when their planned work (the sum of their task cards) represents between four and six hours per day.
Before committing
get a feel for whether they represent an appropriate distribution of work based on the various skills within the team.
everyone on the team is accountable for contributing whatever is within their capabilities, regardless of whether it is their specialty.
If you do find a need to allocate tasks to individuals while planning an iteration, the allocations should be considered temporary and subject to change once the iteration is under way.
When a team makes a commitment to complete a set of stories during an iteration, they need to do so with their maintenance and support load in mind.
Both velocity-driven and commitment-driven iteration planning are viable approaches; however, my preference is for the commitment-driven approach.
velocity plays a critical role in release planning, I do not think it should play an equivalent role in iteration planning.
F...
This highlight has been truncated due to consecutive passage length restrictions.
Second,
Because too few stories are completed in a single iteration for these to average out, I prefer not to use velocity when planning an iteration. However, because these differences do average out over the course of a release, velocity works extremely well for release planning.
To accommodate this, this team decided to run two-week iterations that would start on a Friday and end on a Thursday.
Fridays were spent doing an iteration review and in planning the next iteration.
The team also benefited by occasionally using Friday morning to wrap up any last-minute work they’d been unable to finish on Thursday.
most project managers can hold off giving an estimate for at least one iteration. If that’s your case, use the time to run an iteration and measure the velocity. Then create a range around that one data point, using the cone of uncertainty.
use the cone of uncertainty.
Calculate the average velocity for the iterations you’ve run. Then, for each iteration completed, move one step to the right on the cone of uncertainty.
best way to forecast velocity involves expanding user stories into their constituent tasks, estimating those tasks (as we do when planning an iteration),
the following steps: 1. Estimate the number of hours that each person will be available to work on the project each day. 2. Determine the total number of hours that will be spent on the project during the iteration. 3. Arbitrarily and somewhat randomly select stories, and expand them into their constituent tasks. Repeat until you have identified enough tasks to fill the number of hours in the iteration. 4. Convert the velocity determined in the preceding step into a range.
We should always buffer a given type of project uncertainty with the right units, which means we buffer feature uncertainty with features and schedule uncertainty with time.
