More on this book
Community
Kindle Notes & Highlights
We want to encourage projects on which investment, schedule, and feature decisions are periodically reassessed.
after a traditional schedule has been created and is being reviewed. When we review a schedule showing activities, we do so looking for forgotten activities rather than for missing features.
Further problems occur because activity-based plans often lead to projects that overrun their schedules. When faced with overrunning a schedule, some teams attempt to save time by inappropriately reducing quality. Other teams institute change-control policies designed to constrain product changes, even highly valuable changes. Some of the reasons why activity-based planning leads to schedule overruns include
Work expands so as to fill the time available for its completion.
Important!
The best way of dealing with uncertainty is to iterate. To reduce uncertainty about what the product should be, work in short iterations, and show (or, ideally, give) working software to users every few weeks.
think of a story generally fitting this form: “As a <type of user>, I want <capability> so that <business value>.”
It’s possible to estimate an agile project’s user stories or features in the same way. When I’m at an unfamiliar restaurant and order a large soda, I don’t really know how many ounces I’ll get. About all I do know is that a large soda is larger than a small or medium soda and that it’s smaller than an extra-large one. I also know from experience that when I’m about as thirsty as I am now, a large soda at other restaurants has been the right size. Fortunately, this is all the knowledge I need. And on software projects it’s even easier: All I need to know is whether a particular story or feature
...more
A key tenet of agile estimating and planning is that we estimate size but derive duration.
On any given day, in addition to working on the planned activities of a project, a team member may spend time answering email, making a support call to a vendor, interviewing a candidate for the open analyst position, and attending two meetings. More examples of why ideal time does not equal elapsed time are
This is referred to as triangulation.
A product’s must-have features do not need to be developed in the first iterations of a release. However, because users consider these features to be mandatory, they need to be available before the product is released. Keep in mind, though, that partial implementation of must-have features may be adequate, because gains in customer satisfaction drop off quickly after a base level of support for threshold features has been established. For example, I am writing this book with Adobe FrameMaker, which pays lip service to an undo feature by allowing one level of undo. For me personally, they moved
...more
In Kano analysis, features are segregated into must-have features, linear features, and exciters. This is done by asking potential users two questions about each feature: how they would feel if the feature were
present and how they would feel if it were not present.
Relative weighting provides an approach to assessing the benefits of implementing a feature, the penalties of not implementing it, and the cost into a single v...
This highlight has been truncated due to consecutive passage length restrictions.
Your selection of iteration length should be guided by the following factors: • The length of the release being worked on • The amount of uncertainty • The ease of getting feedback • How long priorities can remain unchanged • Willingness to go without outside feedback • The overhead of iterating • How soon a feeling of urgency is established
“It is better to be roughly right than precisely wrong.”
Haha
This feature buffering process is consistent with that used in the agile process, DSDM (Dynamic Systems Development Method). On DSDM projects, requirements are sorted into four categories: Must Have, Should Have, Could Have, and Won’t Have. DSDM refers to this sorting as the MoSCoW rules. No more than 70% of the planned effort for a project can be targeted at Must Have requirements. In this way, DSDM projects create a feature buffer equivalent to 30% of the duration of the project.
“Why Planning Fails,” Parkinson’s Law says that work expands to fill the time available.
Student syndrome (Goldratt 1997) refers to starting something at the last possible moment that doesn’t preclude successful completion—for example, starting a college term paper three days before it’s due.
Going from vague requirement to working software in one iteration is usually easier on a single-team project than it is when there are multiple teams. On a multiple-team project, it is often appropriate and necessary to put more thought into the user stories before the start of the iteration. The additional detail allows multiple teams to coordinate work.
A feeding buffer, like the schedule buffer of the previous chapter, protects the on-time delivery of a set of new capabilities.
To include a feeding buffer in a release plan, all you need to do is plan temporarily for a lower velocity for the team that is delivering a capability to another team.
conditions of satisfactions are essentially a user story’s high-level acceptance tests. This type of specification by example is very beneficial for the programmers, as they can refer to specific examples of how each function and business rule is expected to work.
On a project, it is far more useful to know how much remains to be done rather than how much has been done.
Planning is an attempt to find an optimal solution to the overall product development question: features, resources, and schedule.
story points are abstract and notional, they are pure estimates of size.
We then estimate a rate of progress, which we call velocity. Our estimates of size and velocity are then combined to arrive at an estimate of duration. Our estimating and planning process benefits from this clear and total separation of estimates of size and duration.
A traditional plan in the form of a Gantt chart, PERT chart, or work breakdown structure focuses on the tasks needed to create a product. An agile plan focuses instead on the features that will be needed in the product.
This is a key distinction, because it forces the team to think about the product at the right level—the features.
A Dozen Guidelines for Agile Estimating and Planning
We see this, for example, in the advice that estimating is best done by the whole team, even though it may be apparent that only one or two specific team members will work on the story or task being estimated.
“The first form of the question is called the functional form; the second is the dysfunctional form to indicate it means a feature is not present. Asking these two questions gives us a better understanding than just asking ‘How much do you want this feature?’ It tells us how the user will feel if the feature is there and how he’ll feel if it isn’t.”
