Why Agile Planning Works
1. Planning At Different Levels - Planning Onion
When setting and revising goals, it is important to remember that we cannot see past the horizon and that the accuracy of a plan decreases rapidly the further we attempt to plan beyond where we can see.
If you are planning a twenty mile trip, you should plan on looking ahead at least five times, once every four miles. A progressive elaboration of the plan is needed.
Agile teams achieve this by planning at three distinct horizons. The three horizons are the Release, the Iteration, and the current Day. The relationships between these (and other) planning horizons can be seen in the planning onion.
Outside the concern of most individual agile teams are product, portfolio, and strategic planning
2. Re-planning Occurs Frequently
At initial stage of the project, release plan is created. Later then at the start of each new iteration a plan for that iteration is created.
The release plan is updated either after each iteration or, at worst, after every few iterations.
Knowing that a plan can be revised at the start of the next iteration shifts a team’s focus from creating a perfect plan (an impossible goal) to creating a plan that is useful right now.
For a plan to be useful it must be accurate, but we accept that early plans will be imprecise. One of the reasons we re-plan is to progressively remove that imprecision.
An agile estimating and planning process recognizes that our knowledge is always incomplete and requires that plans be revised as we learn.
3. Agile Teams Inspect and Adapt
The plan created at the start of any project is not a guarantee of what will occur. In fact, it is only a point-in-time guess. Many things will conspire to invalidate the plan—project personnel may come or go, technologies will work better or worse than expected, users will change their minds, competitors may force us to respond differently or more rapidly, and so on.
Agile teams view every such change as presenting both the opportunity and need to update the plan in order to better reflect the reality of the current situation.
4. Lookahead Planning - Less Detailed Planning At Start
When multiple teams need to coordinate work, the release plan should be updated to show and coordinate the work of the next two or three iterations.
The exact number of iterations will, of course, depend on the frequency and significance of the dependencies between teams. As iterations are completed, details about them are dropped from the plan. The release plan then becomes a rolling lookahead plan that always outlines expectations about the new few iterations.
5. Estimates Of Size and Duration Are Separated
A common planning flaw (on traditional as well as many agile teams) is confusing estimates of size and duration. Clearly the size of an effort and the time needed to complete that effort are related, but there are many additional factors that affect duration. A project of a given size will take programmers of different skill and experience levels different amounts of time. Similarly, duration is affected by the size of the team working on the project. A four-person team may take six months (24 person-months). An eight-person team may reduce that to four calendar months but 32 person-months, even though the project is of the same size in both cases.
Agile estimating and planning succeed because estimates of size and duration are separated. We start by estimating the size of a project’s user stories in story points. Because 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.
6. Plans Are Based On Features, Not Tasks
A traditional plan in the form of a Gantt chart, PERT chart, or WBS 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 forces the team to think about the product at the right level—the features.
When features are developed iteratively there is less need for upfront thinking about the specific tasks necessary. The work of an iteration emerges and the team will think of or discover all of the tasks as they are needed. What’s more important is that the team think about the features that are being developed. When planning by feature, the team has a much better understanding of the product.”
7. Small Stories Keep Work Flowing
On a software project, cycle time is the time from when the team begins work on a feature until it delivers value to users. The shorter the cycle time the better.
This short cycle time is achieved by delivering in small stories. Also small stories are best suitable for providing the best combination of effort and accuracy used in estimating and planning.
8. Tracking Is At The Team Level
Traditional approaches to estimating and planning measure and reward progress at the individual team member level. This leads to a variety of problems. For example, if finishing a task early results in a programmer being accused of giving a padded estimate for the task, the programmer will learn not to finish early. Rather than finish early she won’t report a task as complete until its deadline.
Agile estimating and planning successfully avoid this type of problem by tracking progress only at the team level.
9. Uncertainty Is Acknowledged And Planned For
Many traditional, prescriptive plans make the mistake of believing that features can be locked down at the beginning of a project. Plans are then made that do not allow changes or force changes through an onerous change control process. This leads us to delivering projects with features that users don’t want.
With an agile approach to estimating and planning, teams acknowledge both end and means uncertainty.
End uncertainty (about the product ultimately being built) is reduced as product increments are shown to potential users and other stakeholders at the end of each iteration. Their feedback and responses are used to fine-tune future plans.
Means uncertainty (about how the product will be built) is reduced as the team learns more about the technologies in use and themselves. Early discovery that a particular third-party component cannot meet performance requirements, for example, may lead the team to find an al ternative. The time to find and switch to the new component will need to be factored into new plans once the need is identified.
10. Plan, Estimate & Work As One Team
Critical to the success of a project is that all project participants view themselves as one team aimed at a common goal.
There is no room for a “throw it over someone mentality on an agile project. Analysts do not throw requirements over the wall to designers. Designers and architects do not throw designs over a wall to coders; coders do not throw half-tested code over a wall to testers. A successful agile team work together as one whole team, though there are a number of specific roles on the team (Customer,PO, Scrum Master, Developer).
The more estimating & planning is shared by the team, the more success the team will.
11. Express Uncertainty In Either Functionality/Date
No plan is certain. Agile Plan always have uncertainity factor.
If the amount of new functionality is fixed, state your uncertainty as a date range (“We’ll finish in the third quarter” or “we’ll finish in between 7 and 10 iterations”).
If the date if fixed instead, express uncertainty about the exact functionality to be delivered (Product will include at least these new features but probably no more than those other new features.”).
12. Delivering Something Each Iteration & Frequent Progress Updates
Teams make progress by adding one or more small features in each iteration of releaseable quality or potentially shippable state.
Project’s stakeholders are kept inforrmed about the progress of the project. Burndown charts and other at-a-glance indicators of project progress are used.
Sprint Review Meeting at the end of sprint enable all stakeholders to update thier plans and do product grooming based on customer priorities.
13. Planning Focuses on Business Priorities
Agile teams demonstrate a commitment to business priorities. Teams plan & deliver features in the priorities specified by the product owner, that optimizes the ROI in the project.
This approach of completing and delivering user-valued features rather than on completing isolated tasks is taken care by estimating & plannnig using short user stories.
Agile Plan Buffering for Uncertainty
One of the complaints you notice about agile planning is that it doesn’t work well in some environments. Typically the environments cited are ones in which:
· Project is planned far in advance
· Project must meet a firm deadline and include a reasonably firm set of functionality
· Project is contracted from one organization to another
· Requirements are only understood at a very superficial level
· Organization is uncomfortable allowing too much flexibility in schedules, even on projects that don’t need firm deadlines and deliverables
Being able to create reliable plans in these environments is extremely important. It is often not enough to use just the approach described in above points.
Here missing the deadline, or delivering much less functionality, will damage your company’s reputation in the industry and your reputation within the company. Even if you have a reasonable understanding of the requirements and know who will compose the team (unlike in this case above), the risk of being wrong is significant.
In these cases there is either greater uncertainty or greater implication to being wrong about a release schedule. Because of this, it is useful to Include A Buffer in the determination of the schedule. A buffer is a margin for error around an estimate. In cases where there is significant uncertainty or the cost of being wrong is significant, including a buffer is wise. The buffer helps protect the project against the impact of the uncertainty.
Agile Planning uses two types of buffers: Feature Buffers and Schedule Buffers
Feature Buffers (Keeping Some Amount of Work Optional).
Schedule Buffers (Keeping Some Amount of Extra Time).
Reference: Mike Cohn - Agile Estimating & Planning
Hope this helps.
Regards,
Arun Manglick
No comments:
Post a Comment