Foreword - Jim Highsmith

Agile planning is deceptive. At one level, it's pretty easy - create a few story cards, prioritize them, allocate them to release iterations, then add additional detail to get a next iteration plan.

First, agile teams do a lot of planning, but it spread out much more evenly over the entire project. Second, agile teams squarely face the critical factor that many non-agile teams ignore - uncertainty.

Is planning important? absolutely Is adjusting the plan as knowledge is gained and uncertainty reduced important? absolutely

The agile approach is focused on actually delivering value and not on making outrageous and unachievable plans and commitments.

Agile approaches are "plan-do-adapt", "plan-do-adapt".

But in reality, you are Agile, Extreme or otherwise when you know enough about the practices to adapt them to the reality of your own specific situation. Continuous learning and adaptation are core to agile development.

My Summary

Planning seems easy, but this is a deception.

Planning is spread across the project life cycle, at each planning we use the information gathered in the last cycle.

Agile planning focus on value not on plans.

Foreword - Gabrielle Benefield

Giving a product or project manager sage like qualities to be able to foresee what others, who are experts in their own work, can really deliver is business suicide. Often this approach is really a way of saying yes to the business when asked to deliver on unrealistic goals.

Teams can still be flexible and change course as desired, but it's important to have a roadmap to follow. It's not enough to go fast if you are heading in the wrong direction.

Keeping everything highly transparent, and letting the business know of any changes as they come up, means that the business can adapt quickly to make the best decisions.

My Summary

Saying yes for everything is a business suicide by creating unrealistic goals.

Introduction

Without agile estimating and planning, we cannot have agile projects.

Part I - The problem and the goal

Chapter 1 - The purpose of planning

The team that does no planning cannot answer the most basic questions, such "When will you be done?" and "Can we schedule the product release for June?"

The team that overplans deludes themselves into thinking that any plan can be "right".

The cone of uncertainty shows that during the feasibility phase of a project a schedule estimate is typically as far off as 60% to 160%. That is, a project expected to take 20 weeks could take anywhere from 12 to 32 weeks. After the requirements are written, the estimate might still be off +/- 15% in either direction. So an estimate of 20 weeks means work that takes 17 to 23 weeks.

Why Do It?

Plans and schedules may be needed for a variety of legitimate reasons, such as planning marketing campaigns, scheduling product release activities, training internal users, and so on.

Planning - especially an ongoing iterative approach to planning - is a quest for value.

At the start of a project we may decide that a product should contain a specific set of features and be released on August 31. But in June we may decide that a slightly later date with more features will be better Or we may decide that slightly sooner with slightly fewer features will be better.

A good planning process supports this by

• Reducing risk
• Reducing uncertainty
• Supporting better decision making
• Establishing trust
• Conveying information

Reducing Risk

Some projects are so risky that we may choose not to start once we've learned about the risks. Other projects may contain features whose risks can be contained by early attention.

The project team can opt to eliminate the risk right then by spending time learning about the legacy system. Or risk can be noted and the estimate for the work either made larger or expressed as a range to account for the greater uncertainty and risk.

Reducing Uncertainty

It is critical that this new knowledge be acknowledged and factored into an iterative planning process that is designed to help a team refine their vision of the product.

The most critical risk facing most projects is the risk of developing the wrong product.

The often-cited CHAOS studies ( Standish 2001 ) define a successful project as on time, on budget, and with all features as initially specified. This is a dangerous definition because it fails to acknowledge that a feature that looked good when the project was started may not be worth its development cost once the team begins on the project.

We want to encourage projects on which investments, schedule and feature decisions are periodically reassessed.

The product's users and customer would probably not be satisfied wonderful new feature ideas had been rejected in favor of mediocre ones simple because the mediocre features were in the inital plan.

Supporting Better Decision Making

Organizations need estimates in order to make decisions beyond whether or not to start a project.

We are constantly making decisions between functionality and effort, cost and time.

Establishing Trust

Frequent reliable delivery of promised features builds trust between the developers of a product and the customers of that product.

Reliable estimates enable reliable delivery.

Reliable estimates benefit developers by allowing them to work at a sustainable pace. This leads to higher-quality code and fewer bugs.

Conveying Information

A plan does not guarantee an exact set of features on an exact date at a specified cost. A plan does, however, communicates and establish a set of baseline expectations.

What Makes a Good Plan?

A good plan is one that stakeholders find sufficiently reliable that they can use it as the basis for making decisions.

You determine that the new version will be ready for release in six months. You create a plan that describes a set of features that are certain to be in the new version and another set of features that may or may not be included, depending on how well things progress.

[...] If development takes twelve months instead of the planned six months, that was not a good plan.

[...] However, if the project takes seven months instead of six, the plan was probably still useful. Yes, the plan was incorrect, and yes, it may have led to some slightly mistimed decisions.

[...]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.

What Makes Planning Agile?

Agile planning shifts the emphasis from the plan to the planning.

An agile plan is one that we are not only willing , but also eager to change. We don't want to change the plan just for the sake of changing, but we want to change because change means we've learned something or that we've avoided a mistake.

[...] we need plans that are easily changed. [...] An agile plan is one that is easy to change.

There are many ways we can change the plan without changing the date. We can drop a feature, we can reduce the scope of a feature, we can possibly add people to the project, and so on.

An agile planning:

• Is focused more on the planning than on the plan
• Encourages change
• Results in plans that are easily changed
• Is spread throughout the project

My Summary

The purpose of planning is to answer questions like, "When it will be done?", "Can we schedule the release for June?". If you don't plan you cannot answer, if you plan to much you become delusional that the plan will work.

Planning is a quest for value.

A good planning process reduces risk and uncertainty, establishes trust and convey information, supports better decision making.

A good planning reduces risk either by taking action to reduce it, or increasing the work estimate or estimating it as a range.

A good planning reduces uncertainty, uncertainty of building the wrong product. The definition of a successful project doesn't account the value it delivered, only if it was delivered on time and with the expected scope. A good planning may change once the uncertainty is reduced and the initial plan is validated.

A good planning provides a better decision making by considering functionality, effort, time and cost.

A good planning establishes trust by establishing frequent releases of promised software.

A good planning conveys information, not a commitment of a set of expectation on a date, rather a plan conveys a set of baseline expectations.

A good plan is one that stakeholders find sufficiently reliable that they can use it as the basis for making decisions.

Agile planning changes the focus to the planning instead of focusing on the plan. This means our plans may change, and we are okay with that.

Agile planning is focused on planning and not on the plan. It's spread through all the project, it encourages changes, and therefore plans are easy to change.

Chapter 2 - Why planning fails

• Nearly two-thirds of projects significantly overrun their cost estimates ( Lederer and Prasad 1992 )
• Sixty-four percent of the features included in products are rarely or never used ( Johnson 2002 )
• The average project exceeds its schedule by 100% ( Standish 2001 )

Planning Is By Activity Rather Than Feature

A critical problem with traditional approaches to planning is that they focus the completion of activities rather than on the delivery of features. [ ... ] This becomes how we measure the progress of the team.

A first problem with activity-based planning is that customers get no value from the completion of activities.

When we review a schedule showing activities, we do so looking for forgotten activities rather than for missing features.

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.

• Activities don't finish early
• Lateness is passed down the schedule
• Activities are not independent

Activities Don't Finish Early

Parkinson's law ( 1993 ), which states: Work expands so as to fill the time available for its completion.

If there's a Gant chart hanging on the wall that says an activity is expected to take five days, the programmer assigned to that activity will generally make sure the activity takes the full five days.

It is human nature when ahead of that schedule to fill the extra time with other work that we, but perhaps not others, value.

Lateness Is Passed Down the Schedule

An early start requires a combination of things to go well; a late start can be caused by one thing going wrong.

The problem is compounded because we've already established that activities will rarely finish early. This means that activities will start late and that the lateness will get passed down the schedule.

Activities Are Not Independent

Activities are said to be independent if the duration of one activity does not influence the duration of another activity.

The real knowledge we should gain in a situation like this is that when an activity takes longer than planned, all similar activities are also like to take longer than planned.

Multitasking Causes Further Delays

Clark and Whelwright (1993) studied the effects of multitasking and found that the time an individual spends on value-adding work drops rapidly when the individual is working on more than two tasks.

Additionally, in this example, each of the desire units of work remains in process for twenty days rather than ten, as was the case when the work was done serially.

[...] assumes that I am not slowed by switching among these activities more frequently. The Clark and Whelwright study indicates that a a loss in productivity will occur.

Features Are Not Developed by Priority

Many traditional plans are created with the assumption that all identified activities will be completed. This means that work is typically prioritized an sequenced for the convenience of the development team.

Then, with the end of the project approaching, the team scrambles to meet the schedule by dropping features. Because there was no attempt to work on features in order of priority, some of the features dropped are of greater value than those that are delivered

We Ignore Uncertainty

We ignore uncertainty about the product and assume that the initial requirements analysis led to a complete and perfect specification of the product.

Similarly, we ignore uncertainty about how we will build the product and pretend we can assign precise estimates ("two weeks") to imprecise work.

Even with all this uncertainty, schedules are often expressed as a single, unqualified date: "We will ship on June 30".

As the project progress and as uncertainty and risk are removed from the project, estimates can be refined and made more precise.

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.

Estimates Become Commitments

Each estimate between the end of the week and ten years from now comes with its own probability between 0% and 100% (Armour 2002).

A problem with traditional planning can arise if the project team or its stakeholders equate estimating with committing.

Commitments are made to dates. Normally the date that a team is asked (or told) to commit to is one to which they would assign a less-than-100% probability

My Summary

Planning fails because it focus on the completion of activities rather than of delivery of features. Customers get no value when activities are done.

When we review a a project schedule, we look for incomplete activities not incomplete features.

When a schedule is late, quality is sacrificed.

Because the schedule is usually tight, there is no room for change in the plans, even if there is a high valuable change.

Planning fails because, activities don't finish early, lateness is passed down the schedule, activities are not independent.

Planning fails because activities don't finish early. Parkinson's law proposes that work expands to fulfill the time available for its completion. If we have 5 days to finish a task, it will take more or less 5 days. People will start to look for some hot new technology before starting the new task, adding bells and whistles to the development, or they might even be accused of giving a padded estimate.

Planning fails because lateness is passed down the schedule. Due to the activity based format used in the traditional plans. All activities must finish early in order to the project finish early. However, if one activity delays, the lateness is passed down the schedule. Therefore, it only requires one activity to go wrong to have a later start in the next activity.

Because, the Parkinson's law already defines that we don't finish the task earlier, the work tends to expand, once a project goes late, there is rare change of early completion.

An activity is considered independent if its duration do not influence the duration of another activity. Independent activities might balance the overall duration.

Planning fails because activities are not independent. Most activities are not independent. Therefore, most of the time when one activity delays most of the other activity will delay as well. We should learn with the first activity that we might take a similar time and that we will not balance out.

Multitasking delays the delivery. Multitasking generates waste and reduces. Two examples that show multitasking. Is possible to demonstrate the delay by having 3 activities each during 10 days, focusing one at each time, you deliver each at 10 days, focusing 5 days at each, you delay 10 days the first delivery ( demonstrate the delay ). Counting from A-Z and 1 to 24 . First the letters and after the numbers, or counting one of each ( demonstrate the cognitive waste ).

Planning fails because we focus on activities and not on the most priority feature. Because, the plans assume most activities will be finished by the end, you do not start working on the most important priority activities. When the schedule delays, and you have to drop features, you end up having to drop features more important than the features delivered.

Planning fails because we ignore uncertainty. We believe that the initial work we specified will be the complete and perfect amount of work to be done. Plans that ignore uncertainty and provide a single date are most likely going to fail. As a project progresses, the estimate can be refined and a more precise date can be achieved. We reduce uncertainty, by working in short iterations and delivering working software at the end of it.

Planning fails because we consider estimates as commitment. Each estimate comes with a probability of success. An estimate is a probability, not a commitment. Commitment are made to dates, usually a date where the team has a less than 100% probability of delivering the software.

Chapter 3 - An Agile Approach

[The agile manifest] Their document both gave a name to how they were developing software and provided a list of value statement.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over to following a plan

... a well functioning team of great individuals with mediocre tools will always outperform a dysfunctional team of mediocre individuals with great tools and process.

Agile processes acknowledge the unique strengths ( and weakness) of individuals and capitalize on these rather than attempting to make everyone homogeneous.

[Working software] ... it leads them to have a stable, incrementally enhanced version of the product at the end of each iteration.

... collect early and frequent feedback on both the product and the process.

... we'd like software teams and customers to approach projects with this same attitude of collaboration and shared goals.

Agile teams value responding to change over following a plan because their ultimate focus is on delivering as much value as possible to the project's customer and users.

it's impossible for users to know every detail of every feature they want.

An Agile Approach to Projects

Taken collectively, the four value statements lead to software development processes that are highly iterative and incremental and that deliver coded and tested software at the end of each iteration.

An Agile Team Works As One

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 the wall" mentality on an agile project.

The primary duties of the product owner include making sure that all team members are pursing a common vision for the project, establishing priorities so that the highest-valued functionality is always being worked on, and making decision that lead to a good return on the investment in the project.

The second role is the customer. The customer is the person who has made the decision to fund the project or to buy the software.

I use developer very generally to refer to anyone developing software. That includes programmers, testers, analysts, database engineers, usability experts, technical writers, architects, designers and so on.

Agile project management focus more on leadership than on management.

An Agile Team Works in Short Iterations

Once the project has begun in earnest, all work ( analysis, design, coding, testing and so on) happens concurrently within each iteration.

Iterations are timeboxed, meaning they finish on time even if functionality is dropped. Timeboxes are often very short.

An Agile Team Delivers Something Each Iteration

... during the iteration they transform one or more imprecise requirements statements into coded, tested, and potentially shippable software.

... teams make progress by adding one or more small features in each iteration but that each added feature is coded, tested, and of releasable quality.

Because a single iteration does not usually provide sufficient time to complete enough new functionality to satisfy user or customer desires, the broader concept of a release is introduced.

Releases may occur on varying intervals.

An Agile Team Focuses on Business Priorities

First, they deliver features in the order specified by the product owner, who is expected to prioritize an combine features into a release that optimizes the return on the organization's investment in the project.

For the product owner to have the most flexibility in prioritizing, features must be written so as to minimize the technical dependencies among then.

Second, agile teams focus on completing and delivering user-valued features rather than on completing isolated tasks ( that eventually combine into a user-valued feature).

A user story is a brief description of functionality as viewed by a user or customer of the system.

User stories are free-form, and there is no mandatory syntax.

As a , I want , so that

The story card is just the beginning, though, and each user story is accompanied by as many conversations between the developers and the product owner as needed.

the focus is shifted drastically from written to verbal communication.

An Agile Team Inspects and Adapts

The plan created at the start of any project is not a guarantee of what will occur.

Agile teams view every such change as presenting both the opportunity and need to update the plan to better reflect the reality of the current situation.

At the start of each new iteration, an agile team incorporates all new knowledge gained in the preceding iteration and adapts accordingly.

Perhaps, based on feedback from seeing the software from an earlier iteration, the product owner has learned that user would like to see more of one type of feature and that they don't value another feature as much as was previously thought.

Priorities do tend to be relatively stable from one iteration to the next. However, the opportunity to alter priorities between iterations is a powerful contributor to the ability to maximize the return on the project investment.

An Agile Approach to Planning

... we should not view a project solely as the execution of a series of steps. Instead, it is important that we view a project as rapidly and reliably generating a flow of useful new capabilities and new knowledge.

The new capabilities are delivered in the product; the new knowledge is used to make the product the best that it can be.

New product knowledge helps us know more about what the product should be. New project knowledge is information about the team, the technologies in use, the risks, and so on.

On an agile project, we don't know exactly where the finish line is, but we often know we need to get to it or as close as we can by a know date.

An agile project is more like a timed race than a 10-kilometer race: run as far as possible in sixty minutes. In this way, the agile project team knows when they will finish but not what they will deliver.

When we acknowledge that the result is both somewhat unknown as well as unknowable in advance, planning becomes a process of setting and revising goals that leads to a longer-term objective.

Multiple Levels of Planning

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.

Agile teams achieve this by planning at three distinct horizons. The three horizons are the release, the iteration and the current day.

The goal of release planning is to determine an appropriate answer to the questions of scope, schedule, and resources for a project.

Release planning occurs at the start of a project but is not an isolated effort. A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release.

Based on the work accomplished in the just-finished iteration, the product owner identifies high-priority work the team should address in the new iteration.

... components of the iteration plan can be smaller.

During iteration planning we talk about tasks that will transform a feature request into a working and tested software.

Most agile teams use some form of daily stand-up meeting to coordinate work and synchronize daily efforts.

Product planning involves a product owner's looking further ahead than the immediate release and planning for the evolution of the released product or system.

Conditions of Satisfaction

Every project is initiated with a set of objectives.

These objectives can be thought of as the customer or product owner's conditions of satisfaction - that is, the criteria that will be used to gauge the success of the project.

At the start of release planning, the team and product owner collaboratively explore the product owner's condition of satisfaction. These include the usual items - scope, schedule, budget, and quality - although agile teams typically prefer to treat quality as non-negotiable.

When no feasible solution can be found, the conditions of satisfaction must change.

Once a release plan covering approximately the next three to six months are established, it is used as input into the planning of the first iteration.

For an iteration, the product owner conditions of satisfaction are typically the features she'd like developed next and some high level test about each features.

My Summary

Agile focuses on individuals more than processes. A great team with mediocre tools will outperform a mediocre team with great tools.

Agile focus on working software more than comprehensive documentation. This value regards to increase the functionalities incrementally at the end of each iteration, enabling to get feedback earlier and adding this feedback to the next planning.

Agile focus on customer collaboration over contract negotiation. Everyone working on a project must have the same shared goal, and work together to achieve it.

Agile focus on responding to change over following a plan. At the end of each iteration we add the knowledge we acquired to the next planning.

A very good description:

Taken collectively, the four value statements lead to software development processes that are highly iterative and incremental and that deliver coded and tested software at the end of each iteration.

Although a team has several roles, there is no space for "throw over the wall" mentality. Everyone that is part of the process of developing software participates together creating a "we are all in this together mindset".

The PO ensures the team's prioritizes the most high value features and making decision that lead to a good ROI. The customer is the one that funded or bought the software. Third we have developers (any one that participates in process of developing software). At last, agile project manager executes a leadership role.

Teams works in iterations that are timeboxed. All activities occur concurrently within an iteration.

During the iteration the team transforms specification into a developed and tested functionality. This piece of functionality might be shippable. Because we might not want to ship every sprint, we need the a new concept, the concept of a release. Releases frequency vary.

The team always focus on the highest value feature. The team must try to have features as independent technically as possible. Therefore, the PO will have more flexibility.

The teams focus on features, not activities. The features are usually described as a user story describes the user, the problem, and the value. A user story, although lightweight, goes back and forward between the PO and Dev team until it reaches a development maturity.

Agile teams embraces changes on plans. Most of the times the iterations are stable, and teams have the in between iterations to change the priority of the next iteration based on what you learned in the current iteration.

A project is not a execution of steps. A project is the generation of capabilities and of knowledge. At each iteration the team acquires knowledge about itself, technology, risk the product. There are two types of knowledges acquired at each iteration, technical and business knowledge. The technical knowledge regards to reassessing after the implementation time the difficulties with the technology, usually you also learn about the risks and reduce uncertainties. Business knowledge regards to what we learned about the product in the last iteration.

In agile project, you usually don't know where the finish line is. Is more like a race against time, that you know that you'll finish, but you don't know what you will deliver. Therefore, because we understand the finish line is unknown and unknowable, planning become an exercise of revisiting goals and the next steps.

The accuracy of plans reduce when looking to much further in the future. Agile teams plan releases, iterations and daily.

The release planning answers the scope, schedule and resources necessary to deliver. The release plan starts at the beginning of a project, and is updated after each sprint.

Iteration planning answers the question of what is the next highest valuable item the team have to work. Iteration items are small components that will be transformed from specification to developed and tested feature.

In the daily planning, the team synchronizes and plan the tasks until the next day always looking to complete the most important tasks in the iteration.

There are other levels of planning, for example, product planning which is more about discovery.

Every project has a set of objectives. We use these objectives to measure if the project was successful or not. At the release planning the team discusses the project's condition of satisfaction (cost, schedule, scope). Agile teams prefer to not negotiate quality.

If the team does not finds an agreement the satisfaction condition must be changed. Once the release planning is established we used that information to fulfill the iteration planning.

Part II - Estimating Size

agile teams separates estimation of size from estimates of duration.

Chapter 4 - Estimating Size with Story Points

[Restaurants] In cases such as these, you are ordering by relative rather than measured size.

All I need to know is whether a particular story or feature is larger or smaller than other stories and features.

Story Points are relative

Story Points are a unit of measure for expressing the overall size of a user story.

The raw values we assign are unimportant. What matters are the relative values.

[SP] ... is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on.

Once you've fairly arbitrarily assigned a story-point value to the first story, each additional story is estimated by comparing it with the first story or with any others that have been estimated.

On an agile project it is not uncommon to begin an iteration with incompletely specified requirements, the details of which will b e discovered during the iteration.

When you're given a loosely defined user story (or dog), you make some assumptions, take a guess, and move on.

Velocity

Velocity is a measure of a team's rate of progress.

It's calculated by summing the number of story points assigned to each user story that the team completed during the iteration.

Desired Features -> Estimate size -> estimate duration -> Schedule.

If we sum the story-points estimates for all desired features we come up with a total size estimate for the project. If we know team's velocity we can divide size by velocity to arrive at an estimated number of iterations.

A key tenet of agile estimating and planning is that we estimate size but derive duration.

Velocity Corrects Estimation Errors

[About lower velocity than expected] Without re-estimating any work they will have correctly identified that the project ill take ten iterations rather than eight.

2In fact, your estimates remain useful because they are estimates of the relative effort.

The beauty of this is that estimating in story points completely separates the estimation of effort from the estimation of duration.

My Summary

Story Points are a relative unit of measure. It represents the effort, complexity, risks and so on of a user stories.

We say it's a relative unit of measure because it's always relative to other story points. An User Story with 4 story points is twice big than an story points with 2.

The Story points are a good match for agile projects, where you might not have all the requirements beforehand.

We use the velocity to understand the team's rate of progress. We calculate it by summing all SP completed from an iteration. You can also create an average from several iterations.

To come up with a schedule, we list all the desired features, we estimate the effort and derive the duration, therefore we can come up with an expected range of date.

Even though we fail to estimate the duration of a development ( velocity is lower than expected ). The estimate holds true, because it's relative.

Chapter 5 - Estimating in Ideal Days

Ideal time is the amount of time that something takes when stripped of all peripheral activities.

Elapsed time is the amount of time that passes on a clock ( or perhaps a calendar).

It's almost always far easier and more accurate to predict the duration of an event in ideal time than in elapsed time.

[Football analogy] To come up with an estimate that will be as accurate as your off-the-cuff ideal time estimates, you would need to consider each of these factors [amount of faults, injuries, weather, team's strategy].

Finally, after decades of televising football games, the network have accustomed us not to expect a precise finish time.

Ideal Time and Software Development

Why ideal time does not equal elapsed time are:

• Supporting the current release
• Sick time
• Meetings
• Demonstrations
• Personnel Issues
• Phone calls
• Special projects
• Training
• Email
• Reviews and walk-through
• Interviewing candidates
• Task switching
• Bug fixing in current releases
• Management reviews

Problems can arise when a manager asks a team member the inevitable question: "How long will this take?" The team member responds, "Five days", so the manager counts off five days on her calendar and marks the day with a big red X. The team member, however, really meant to say, "Five days if that's all I do, but I do a lot of other things, so probably two weeks.".

A software developer who is told to multitask loses a great deal of efficiency while switching between two (or more) tasks.

• The story being estimated is the only thing you'll work on.
• Everything you need will be on hand when you start.
• There will be no interruptions.

Ideal Days as a Measure of Size

When we estimate the number of ideal days that a user story will take to develop, test, and accept, it is not necessary to consider the impact of the overhead of the environment

The amount of time that elapses on a clock (or calendar) will differ of course.

Then an estimate of size expressed as a number of ideal days can be converted into an estimate of duration using velocity in exactly the same way as with story points.

One Estimate, Not Many

If you choose to estimate in ideal days, assign one aggregate estimate to each user story.

This level of focus on individual roles on a team shifts team thinking away from the "we're all in this together" mentality we'd like to exist on an agile team.

Further, it vastly increases the amount of work necessary to plan a release.

A team in this situation [developers for specific platforms] may want to estimate the ideal time for each role on each story. They should, however, be aware of the extra administrative burden this will require.

My Summary

Ideal time is different from elapsed time. We often give ideal time estimates and these are used as elapsed time. Ideal time is the 90 minutes from a US football game, elapsed time is the time on the watch or on the calendar varying depending on several aspects of the game.

The daily routine impacts the ideal time. Slack messages, support, e-mails, trainings, and so on...

Multitask is a second factor that impacts the ideal time.

When we estimate with ideal time. We consider we'll be working only in the story being estimated. That everything we'll need to begin will be on hand. and there'll be no interruptions.

When we estimate with ideal time, we don't consider the company's bureaucracy. Therefore, ideal time should be the same on a start up or enterprise company. The elapsed time may change.

We should give one estimate for the whole team, to avoid not follow the "we're all in this together" mentality.

Chapter 6 - Techniques for Estimating

We want to remain aware, too, of the diminishing return on time spent estimating. We can often spend a little time thinking about an estimate and come up with a number that is nearly as good as if we had spent a lot of time thinking about it.

First, no matter how much effort is invested, the estimate is never at the top of the accuracy axis.

Little effort is required to move the accuracy up dramatically from the baseline.

Finally, notice that eventually, the accuracy of the estimate declines.

When starting starting to plan a project, it is useful to think about where on the curve we wish to be. Many projects try to be very high up the accuracy axis, forcing teams far out on the effort axis even though the benefits diminish rapidly. Often, this is the result of the simplistic view that we can lock down budgets, schedules and scopes and that projects success equates to on-time, on-budget delivery of an up-front, precisely planned set of features. This type of thinking leads to a desire for extensive signed requirements documents, lots of up-front analysis work, and detailed project plans that show every task a team can think. Then, even after all this additional up-front work, the estimates still aren't perfect.

Agile teams, however, choose to be closer to the left (in the curve). They acknowledge that we cannot eliminate uncertainty from estimates, but they embrace the idea that small efforts are regarded with big gains.

Estimates Are Shared

Estimates are not created by a single individual on the team. Agile teams do not rely on a single expert to estimate. Despite well-known evidence that estimates prepared by those who will do the work are better than estimates prepared by anyone else (Lederer and Prasad 1992).

On an agile project we tend not to know specifically who will perform a given task.

others may have something to say about her estimate. (Example: Considering previous experience someone had )

The Estimation Scale

we are best at estimating things that fall within one order of magnitude.

Two estimation scales I've had good success with are

1,2,3,5 and 8

1,2,4 and 8

These nonlinear sequences work well because they reflect the greater uncertainty associated with estimates for larger units of work.

Each of these numbers should be thought of as a bucket into which items of the appropriate size are poured. Rather than thinking of work as water being poured into the buckets, think of the work as sand.

Assigning a nonzero values to tiny features will limit the size of largest features.

Secondly, if the work truly is closer to 0 than 1, the team may not want the completion of the feature to contribute to its velocity calculations.

I've never had the slightest problem explaining this to product owners, who realize that a 0-point story is the equivalent of a free lunch. However, they also realize there's a limit to the number of free lunches they can get in a single iteration.

User Stories, Epics and Themes

For features that we're not sure we want ( a preliminary cost estimate is desired before too much investment is put int them) or for feature that may not happen in the near future, it is often desirable to write one much larger user story. A large user stories is sometimes called an epic.

Additionally, a set of related user stories may be combined ( usually by a paper clip if working with note cards) and treated as a single entity for either estimating or release planning. Such a set of user stories is referred to as a theme.

However, it's important that they realize that estimates of themes and epics will be more uncertain than estimates of the more specific, smaller user stories.

Deriving an Estimate

• Expert opinion
• Analogy
• Disaggregation

Expert Opinion

The expert relies on her intuition or gut feel and provides an estimate.

This approach is less useful on agile projects than on traditional projects. On an agile project, estimates are assigned to user stories or other user-valued functionality.

A nice benefit of estimating by expert opinion is that it usually doesn't take very long.

Analogy

If the story is twice the size, it is given an estimate twice as large.

Instead, you want to estimate each new story against an assortment of those that have already been estimated.

Disaggregation

Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces.

However, you need to be careful not to go too far with this approach.

Planning Poker

Planning poker combines expert opinion, analogy and disaggregation into an enjoyable approach to estimating that results in quick but reliable estimates.

The Right Amount of Discussion

Buy a two-minute sand timer, and place it in the middle of the table where planning poker is being played. Anyone in the meeting can turn the timer over at any time.

Smaller Sessions

This isn't ideal but may be a reasonable option, especially if there are many items to be estimated, as can happen at the start of a new project.

When to Play Planning Poker

First, there will usually be an effort to estimate a large number of items before the project officially begins or during its first iterations.

Second, teams will need to put forth some ongoing effort to estimate new stories that are identified during an iteration.

Kent Beck suggests hanging an envelope on the wall with all new stories placed in the envelope.

Why Planning Poker Works

First, planning poker brings together multiple expert opinions to do the estimating.

Second, a lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates.

Third, studies have shown that averaging individual estimates leads to better results ( Hoest and Wohlin 1998)

My summary

Considering two axis X that represents effort and Y that represents estimate accuracy. In the start of the axis X with little effort you can get a lot of accuracy. As we progress in the axis X we reduce the amount of accuracy we get, until eventually we start to get an decline in the accuracy. Therefore, we can never have an estimate that is 100% accurate.

With that in mind, is preferable to invest effort until you reach a good enough estimate. And avoid wasting effort to get an worse result. Agile teams are usually in the beginning of the axis X.

Even though there are evidence that experts have a better estimate, in agile teams the whole team participate in the estimation. That's because we don't know who will do the task and because team members can also help the expert with information from similar tasks from the past.

When estimating we want to keep things in the same order of magnitude. Avoid comparing the distance going to the shop and the distance going to the moon.

The most common sequences are Fibonacci and 0,1,2,4,8. These sequences are good because the gap between the number increases exponentially which is a good representation for the uncertainty. The bigger the story more uncertain it is.

Assigning zero to your scale reduce the largest value of the scale, which is good. It's also good to document the tasks that we have to do that individually the effort is so small it won't impact the velocity. Just be careful because there's a limit of free lunches. Many 0 user stories can be grouped in a unique user story with a bigger size.

Consider the values in the scale as a sand, you can put a little more sand than the bucket max size.

There are three ways to get an estimate. Through an expert, doing analogies or disaggregating user stories.

An estimate based on the expert relies on its experience and gut feel. It's less valuable in agile projects that we don't assign the tasks for each person. It's fast to do.

An estimate based on analogy to reach an estimate you compare with a set of other user stories. If this user story is twice asH big as that one, then you have your estimate.

An estimate based on disaggregation you start with a big story and start to break it into smaller ones. Be careful to not break to much, otherwise you might end up with a broader estimate.

Planning poker is the combines the three estimation techniques. To limit the amount of discussion in a planning poker, you can put a sand timer in the table an anyone can start it at any time of a discussion.

When to estimate, in beginning of a project you might have to expend a extra effort estimating user stories. Then, during each iteration of a the project, you need to estimate the new items that come up.

Planning poker works because it uses the three techniques described above, it provides discussion about the topic and it is based on individuals average estimates.

Chapter 7 - Re-estimating

... velocity is the great equalizer.

as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.

My summary

If you break the consistency between the user story you estimate and the user stories you completed, the velocity will not reflect the reality.

When you learn something about the estimates you should re-estimate the sprint velocity and the backlog user stories relative to it.

Consider that you have the following user stories and its story points:

• Chart A - 3
• Chart B - 5
• Chart C - 3
• Text Report - 3
• Upload - 3
• Recommendation - 5

In the first iteration the teams pulls Chart A, Chart B and Recommendation, adding to 11 Story points.

At the end of the first iteration the team completed only Chart A and Recommendation, therefore, team's velocity is 8. Chart A took more effort than expected.

The team has 3 scenarios:

1. Team do not re-estimate: The next iteration the team pulls Chart B and Chart C. The next iteration will most likely fail.
2. Team re-estimate the finished story: The team re-estimate Chart A to 6, twice as big as they firstly estimated. Teams velocity increases to 11. The next iteration the teams pulls 11 story points (Chart B, Chart C and Text Report). The next iteration will most likely fail.
3. Re-estimating when relative size changes: The team re-estimate Chart A to 6 and all the user stories that are relative to it like Chart B and Chart C. Therefore, the Chart B changes its estimate to 10 and Chart C to 6. Team's velocity increases to 11. The next iteration the team pull only the Chart B.

In the third scenario the team learned with the Chart A user story and applied the knowledge to the other user stories that are related to it.

Usually, if the team didn't complete the whole user story they do not add its size to the velocity calculation. An exception would occur if the team completes half of a user story, and during the next iteration they will not work on the other half. In this case, you could split the user stories in two, and add the story points to from the completed part to the velocity.

Chapter 8 - Choosing between Story Points and Ideal Days

Story Points Help Drive Cross-functional Behavior

Story points estimate needs to be a single number that represents all the work for the whole team, estimating story points initiates high-level discussions about everything that will be involved.

My summary

There are 5 points in favor of Story points:

• Story-points help drive cross-functional behavior. There is only one estimate for the whole team. In opposition, in ideal time each role calculates the time they require.
• Story-points estimates do not decay. Because story points do not consider any time, the estimate remains the same even though the velocity might change. Ideal Points need to re-estimate if the team evolves technically.
• Story points are a pure measure of size. You can estimate by analogy only (which has evidence that is better). No temptation to compare then with the reality.
• Estimating in story points is typically faster. Estimates in story points are more high-level and therefore consume less time.
• My ideal days are not your ideal days. Even though you can agree on the effort required you might disagree with the time necessary to complete the task.

There are 2 points in favor of ideal days:

• Ideal days are easier to explain outside the team. Everyone understands that not every minute of the work day is spent programming, testing, designing or otherwise making progress towards new features. Considering the story points, you have a longer path to explain to everyone, though it's an excellent opportunity to teach about the cone of uncertainty , progressive refinement and how velocity impacts the schedule.
• Ideal days are easier to estimate at first. Similarly, most people are used to the concept of estimating time to tasks. With Story points again you have a longer path.

Part III - Planning for Value

Before planning a project, we must consider what it is that our users need. Simply generating a list of things we think they want and then scheduling the development of those features is not enough. Achieving the best combination of product features(scope), schedule, and cost requires deliberate consideration of the cost and value of the user stories and themes that will comprise the release.

Chapter 9 - Prioritizing Themes

There is rarely, if ever, enough time to do everything. So we prioritize.

Factors in Prioritization

1. Financial value of having the features
2. The cost of developing (and perhaps supporting) the new feature.
3. The amount of significance of learning and new knowledge created by developing the features.
4. The amount of risk removed by developing the features.

Cost

An important, yet often overlooked, aspect of cost is that the cost can change over time.

The best way to reduce the cost of change is to implement a feature as late as possible - effectively when there is no more time for change.

New Knowledge

On many projects, much of the overall effort is spent in the pursuit of new knowledge.

• Knowledge about the product
• Knowledge about the project

The flip side of acquiring knowledge is reducing uncertainty.

End uncertainty is reduced by acquiring more knowledge about the product.

Means uncertainty is reduced through acquiring more knowledge about the project.

A project following a waterfall process tires to eliminate all the uncertainty about what is being built before tackling the uncertainty of how it will be built.

...the complete upfront elimination of all end uncertainty is unachievable.

...one of the greatest risks to most projects is the risk of building the wrong product. This risk can be dramatically reduced by developing early those features that will best allow us to get working software in front of or in the hands of the actual users.

Risk

is anything that has not yet happened but might and that would jeopardize or limit the success of the project.

To prioritize work optimally, it is important to consider both risk and value.

The high-value, high-risk features should be developed first. These features deliver the most value, and working on them eliminates significant risks.

Next are the high-value, low-risk features. These features offer as much value as the first set, but they are less risky. Therefore, they can be done later in the schedule.

Next are the low-value, low-risk features. These are sequenced third because they will have less impact on the total value of the product if they are dropped, and because they are low risk.

features that deliver low value, but are high risk are best avoided.

My summary

Because we have limited money and time we need to prioritize.

There are 4 things to consider:

1. Value. How much money the organization will make or save?

2. Cost. How much money it will cost to develop (time vs team salary)? How much money it will cost to maintain? How much it will cost if will do it later

   Cost may change with time.

3. New knowledge. The overall effort of projects is in pursuit of new knowledge. There are 2 types:

   1. Knowledge about the product (What) or End uncertainty
   2. Knowledge about the project (How) or Means uncertainty

   Acquiring knowledge reduces uncertainty. It's not possible to reduce all the uncertainty. Waterfall projects try to remove all the What and How before they start the project. Agile projects reduces the risk as it goes. At the beginning of the project there's a higher effort to reduce the End uncertainty to be sure we are not building the wrong product.

4. Risk. Anything that might happen during the project that might put it on jeopardize or limit the success of the project.

To prioritize work optionally we must consider both value and risk.

1. High value, high risk
2. High value, low risk
3. low value, low risk

Avoid low value, high risk.

You can start considering the value it will deliver and the cost it will have. Also consider the cost in the long term. Then start to move forward or backwards to see the difference between the outcomes.

Chapter 10 - Financial Prioritization

"As a general rule of thumb when benefits are not quantified at all assume there aren't any." - Tom DeMarco and Timothy Lister

At a minimum , whoever requested the theme should be able to quantify the reasons for developing it.

(About the Theme-Return Worksheet) We cannot compare projects and make priorization decisions simply by summing the total row of a worksheet like Table 10.2 for each theme.

Sources of Return

The return on a project can come from a variety of sources. For convenience, we can categorize these as new revenue, incremental revenue, retained revenue and operational efficiencies.

(Incremental revenue) incremental revenue from existing customers.

Retained revenue refers to the revenue an organization will lose if the project or theme is not developed.

No organization is ever as efficient as it could be. There's always some task that could be streamlined or eliminated.

Often, the drive to improve operational efficiencies comes from anticipated growth. An inefficiency that may not be a problem today rapidly becomes a problem when the company becomes much larger.

• Anything that takes a long time or that would take a long time if the company grew.
• Better integration or communication between departments
• Reduced employee turnover
• Shorter training time for new employees
• Any time-sensitive process
• Combining multiple processes
• Anything that improves accuracy and reduces rework

(unless we can find a way to deliver partial solution, which should always be a goal)

Financial Measures

The amount I have to invest today to have a known amount in the future is called the present value.

The process of moving future amounts back into their present value is known as discounting.

The rate at which organization discount future money is known as their opportunity cost and reflects the percentage return that is passed up to make this investment.

My Summary

You should at minimum be able to quantify the benefits of developing something, otherwise you cannot prioritize based on facts.

You can held a meeting with your team members for each theme to categorize the types of return you are getting from a theme. There are several types of return, but the book presents four:

• New revenue: Revenue from new customers.
• Incremental revenue: Revenue from existing customers.
• Retained revenue: Revenue that is not lost because of the project.

• Operational efficiency: Revenue from improving the system or the process. For example:

  • Long, manual, tedious and error prone tasks that don't scale
  • Improve of accuracy and reduces rework
  • ...

There are financial measures that can be used to prioritize the theme:

• Net Present Value
• Internal Rate of Return ( IRR or ROI )
• Payback period
• Discounted Payback period

Chapter 11 - Prioritizing Desirability

Kano Model of Customer Satisfaction

The process of doing so was originated by Noriaki Kano, whose approach gives us a way to separate feature into three categories:

• Threshold, or must-have, features
• Linear features
• Exciters and delighter

In fact, exciters ad delighters are often called unknown needs because customers or users do not know they need these features until they see them.

... once some amount of a must-have feature has been implemented, customer satisfaction cannot be increased by adding more of that feature. Also, no matter how much of a must-have feature is added, customer satisfaction never rises above the midpoint.

customer satisfaction rises drastically based on even a partial implementation of an exciter or delighter feature.

direct relationship between the inclusion of linear features and customer satisfaction.

emphasis should be placed on prioritizing the development of all threshold features.

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.

Secondary emphasis should be placed on completing as many linear features as possible. Because, each of these features leads directly to greater customer satisfaction, the more of these features that can be included the better (excluding, of course, such situations as a product that is already bloated with too man features).

Keep in mind that features tend to migrate down the Kano diagram over time.

determining the category of a feature by asking two questions: one question regarding how the user would feel if the feature were present in the product and one question about how the user would feel if it were absent.

(about features with high values for two responses) This indicates that different types of customers and users have a different expectations.

Relative Weighting: Another Approach

Rather than use questionnaires, this approach relies on expert judgment.

estimates of benefits and penalties are relative.

My Summary

Proposes two methods for prioritizing considering user's desiribility:

• Kano Model

  • Three categories
  • Must-have: Its absence causes low customer satisfaction. Its presence guarantees at maximum a neutral customer.
  • Linear features: Its absence causes low customer satisfaction. Its presence guarantees customer satisfaction. The amount of features is linear to the customer satisfaction.
  • Exciters / delighter: Its absence do not causes low customer satisfaction. Its presence guarantees customer satisfaction. This kind of feature has a exponential impact in the customer satisfaction.
  • Priorization must follow must-have, then linear features and at last exciters / delighter.
  • Use a questionnary with users to access the Kano Model. You should ask two questions:
  • How do you feel with the feature present?
  • How do you feel with the feature absent?
  • Use the following scale for the answers:
  • I like it
  • I expect it to be that way
  • I am neutral
  • I can live with it that way
  • I dislike it that way

• Relative Weighting

  • Relies on experts
  • For each theme estimate benefits and penalties.
  • Sum the Relative benefits and penalties to reach the feature Total Value.
  • Divide each item by the total value to reach the % Value of each theme.
  • Add an estimate for each theme. And sum the estimate.
  • Divide the each estimate by the Sum of estimate to understand the % Cost of each theme.
  • At last, divide the % Value by the % Cost and you'll reach to a Priority for each theme.

Chapter 12 - Splitting User Stories

When to Split a User Story

First, a user story should be split when it is too large to fit within a single iteration.

Second, it can be useful to split a large user story (an epic) if a more accurate estimate is necessary.

Splitting across Data Boundaries

Split large stories along the boundaries of the data supported by the story.

In some cases a large story can be made much smaller by removing the handling of exceptional or error conditions from the main story.

Splitting on Operational Boundaries

Split large stories based on the operations that are performed within the story.

A common approach to doing this is to split a story along the boundaries of the common CRUD operations - Create, Read, Update and Delete.

Removing Cross-Cutting Concerns

Consider removing cross-cutting concerns (such as security, logging, error handling and so on) and creating two versions of the story one with an one without support for the cross cutting concern.

Don't Meet Performance Constraints

Consider splitting a large story by separating the functional and nonfunctional aspects into separate stories.

Split Stories of Mixed Priority

Split a large story into smaller stories if the smaller stories have different priorities.

Don't Split a Story into Tasks

Delivering a cohesive subset of all layers of a feature is almost always better than delivering all of one layer.

Don't split a large story into tasks. Instead, try to find a way to fire a tracer bullet through the story.

Avoid the Temptation of Related Changes

Avoid making things worse by adding related changes to an appropriately sized feature unless the related changes are of equivalent priority.

Combining Stories

Just as we may need to split large stories, we may need to combine multiple tiny stories.

My Summary

You should split a story when won't fit in the iteration. Either because it's too big or because you won't be able to finish it. You should split it based on:

• The data
• The operations
• Cross-Cutting concerns (security, logging, error handling, ...)
• Non-functional requirements
• Different priorities within the story

You shouldn't:

• Split a story into tasks. It's better to do the tracer bullet.
• Split and than add more work to the User story

You may as well combine tiny user stories into a larger user story. This approach is commonly used for bugs.

Chapter 13 - Release Planning Essentials

Release planning is the process of creating a very high-level plan that covers a period longer than an iteration.

The sooner the product can be released( and the better it is when it's released), the sooner the organization will begin earning a return on its investment in the project.

Second, a release plan conveys expectations about what is likely to be developed and in what timeframe.

Third, a release plan serves as a guidepost toward which the project team can progress.

The Release Plan

Multiplying the planned number of iterations by either the expected or known velocity of the team gives us the total amount of work that can be performed.

1. Determine conditions of satisfaction
2. Estimate the user stories

3. Do in any sequence

   1. Select an iteration length
   2. Estimate velocity
   3. Prioritize user stories
4. Select stories and a release date

Determine the Conditions of Satisfaction

it is important to know the criteria by which the project will be evaluated as a success or a failure

Projects are typically either date-driven or feature-driven. A date-driven project is one that must be released by a certain date but for which the feature set is negotiable. A feature-driven project is one that we would probably like to release as son as possible but for which we consider the completion of a set of features to be more important.

Estimate the User Stories

an estimate represents the cost of developing a user story.

Prioritize User Stories

A good product owner will accept ultimate responsibility for prioritizing but will listen to advice from the development team, especially about the sequencing.

My Summary

A release plan is a high-level plan bigger than a iteration and serves as a guidance for a set of iterations. The release plan conveys the expectations for a timeframe. The earlier the release goes to production earlier you have return from it.

A project must have a set of conditions that determine whether it will fail or succeed, usually there are three: schedule, scope, resources.

You can have either date-driven or feature-driven projects:

• Date-driven: The date is fixed, but the scope is negotiable. Calculate the number of iterations until the end date. Multiply the velocity by the number of iterations to achieve the amount of effort you can deliver.
• Feature-driven: The scope is fixed, but the date is negotiable. Sum the amount of effort for each user story. Divide the total effort by the velocity, and you'll get the total number of iterations.

Once you have the release plan, you must update it as the project proceeds. A release plan must not be static.

Chapter 14 - Iteration Planning

With an iteration plan, a team takes a more focused, detailed look at what will be necessary to implement completely only those user stories selected for the new iteration.

( about the iteration planning meeting) Anyone involved in taking a raw idea an turning it into a functioning product should be present.

One of the most significant advantages to using note cards during iteration planning is that it allows everyone to participate in the process.

Tasks Are Not Allocated During Iteration Planning

Individuals do not sign up for tasks until the iteration begins and generally sign up for only one or two related tasks at a time. New tasks are not begun until previously selected ones are completed.

The primary purpose of iteration planning is to refine suppositions made in the ore coarse-grained release-plan.

agile planning becomes a two-stage process. The first stage is the release plan, with its rough edges and general uncertainties. The second stage is the iteration plan. An iteration plan still has some rough edges and continues to be uncertain. However, because it is created concurrent with the start of a new iteration, an iteration plan is more detailed than a release plan.

Velocity-Driven Iteration Planning

1. Do in any sequence

   1. Adjust priorities
   2. Determine target velocity
2. Identify an iteration goal
3. Select user stories
4. Split user stories into tasks
5. Estimate tasks

The default assumption by most teams is that their velocity in the next iteration will equal the velocity of the most recent iteration. Beck and Fowler(2000) call this yesterday's weather.

Other teams prefer to use a moving average over perhaps the last three iterations.

The goal succinctly describes what they would like to accomplish during that period.

Next, the product owner and team select stories that combine to meet the iteration goal.

A common question around iteration planning is what should be included. All tasks necessary to go from a user story to a functioning, finished product should be identified.

An agile teams has the goal of fixing all bugs in the iteration in which they are discovered.

A spike is a task included in an iteration plan that is being undertaken specifically to gain knowledge or answer a question.

The tasks you create should be of an approximate size so that each developer is able to finish an average of one per day.

larger tasks should be generally understood to be placeholders for one or more additional tasks that will be added as soon as they are understood.

Commitment-Driven Iteration Planning

1. Adjust priorities
2. Identify an iteration goal

3. Repeatedly while commitment is not full

   1. Select a story to add
   2. Expand the story into tasks
   3. Estimate tasks
   4. Team commits to story
4. Iteration planning is done

summing the estimates still gives some indication of the overall size of the work

The key is that everyone on the team is accountable for contributing whatever is within their capabilities, regardless of whether it is their specialty.

My Summary

Iteration plan describes the work expected for one iteration of the release plan. This is a more detail and focused plan.

The iteration plan is created during a iteration planning meeting, There are some steps expected in this meetings that vary depending on the type of plan you are doing. There are two types:

• Velocity-driven: You plan based on your team's last velocity.
• Commitment-driven: You plan based on the team's commitment.

The first step for either type of plan requires that the team prioritize the work to come. The team can use the iteration review meeting to do so.

During the Iteration review meeting everyone interested in the project will be see the progress of that iteration, and they can provide valuable feedback. This feedback might change the priority for the next iteration. Because a iteration review plus a iteration planning can be very tiring, you may choose to have a priorization meeting few days before the end of the iteration. This way you have a close enough knowledge whether the team will complete their iteration goal, and you are fresh to discuss the priorization for the next iteration.

The second step is to identify a goal for your iteration. The work you will select in the next steps should represent what the teams need to do to accomplish the goal.

The third step depends on the type of plan:

For velocity-driven, select a user story with the highest priority, expand its task and estimate it. Repeat until you have reached the team's velocity from previous iterations.

For commitment-drive, select a user story with the highest priority, expand its task and estimate it. Then, the teams decides whether it can commit to that user story for this iteration. Repeat until the team cannot commit to more user stories.

When expanding the tasks, you should consider all work necessary to put the user story to production.

Chapter 15 - Selecting an Iteration Length

Factors in Selecting an Iteration Length

• 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

Iteration length should be chosen to maximize the amount, frequency, and timeliness of feedback to the whole team.

Naturally, one of the goals of a successful agile team is to reduce(or nearly eliminate) the overhead associated with each iteration.

Making a decision

One of the main goals in selecting an iteration length is finding one that encourages everyone to work at a consistent pace throughout the iteration. If the duration is too long, there is a natural tendency to relax a bit at the start of the iteration, which leads to panic and longer hours at the end of the iteration.

My favorite technique to help reduce this strain is follow a macro-cycle of six two-week iterations followed by a one-week iteration. I refer to this cycle as "6 x 2 + 1". During the two-week iterations, the team works on items prioritized by the product owner. During the one-week iteration, however, the team chooses its own work.

My Summary

There are several reasons to why you should change the length of an iteration (see the bullets above). The length of the iteration will vary accordingly to your context. A project with a lot of uncertainty you might want shorter iterations. A project where you can only access your customer or users monthly you might choose a longer iteration.

At the end of the iteration, you don't want to add overhead work (like manual tests and so on) to your next iteration. Focus on reducing it or eliminate.

When making a decision focus on finding a consistent pace. A pace where the team can follow indefinitely and sustainably. You may also apply a "6 x 2 + 1" technique. After every 6 iterations of two week, the team has 1 iteration free to focus on work they can prioritize. This helps to reduce technical debt, and continuously improve the system.

Chapter 16 - Estimating Velocity

• Use historical value
• Run an iteration
• Make a forecast

if you need to estimate velocity you should consider expressing the estimate as a range.

Use Historical Values

Any personnel or significant technology change will reduce the usefulness of historical measures of velocity.

start by calculating the team's average velocity over the course of the preceding release.

Run an iteration

An ideal way to forecast velocity is to run an iteration( or two or three) an then estimate velocity from the observed velocity during one to three iterations.

Some organizations will resist starting a project without having a more specific idea how long it will take. In such cases, stress that the need to run a few iterations first stems not from a desire to avoid making an estimate, but to avoid giving an estimate without adequate foundation.

Make a Forecast

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.

My Summary

Always use velocity as a range.

• Historical velocity: team's historical velocity (other projects).

  • Best and worst velocities
  • Subtract and add to the average velocity
  • Multiply by the uncertainty cone
• Run an iteration: Should be the default. Observed velocity.

• Make a Forecast: Last option.

  • Define the project scope using user stories
  • Create a "plan an iteration" with stories from the scope
  • Determine based on the velocity of this fake iteration the total number of iteration to delivery all the scope.

Chapter 17 - Buffering Plans for Uncertainty

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 help protect the project against the impact of the uncertainty. In this way, buffering a project schedule becomes an appropriate risk management strategy.

Feature Buffers

First the customer selects all of the absolutely mandatory work. The estimates for that work are summed. This represents the minimum that can be released. The customer then selects another 25% to 40% more work , selecting toward the higher end of the range for projects with more uncertainty or less tolerance for schedule risk. The estimates fort this work are added to the original estimate, resulting in a total estimate for the project. The project is then planed as normal for delivery of the entire set of functionality; however some amount of the work is optional and will be included only if time permits.

On DSDM (Dynamic Systems Development Method) projects, requirements are sorted int 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 prospect can be target at must have requirements.

Schedule Buffers

the departure time is fixed, just like deadlines are on many software development projects. In this case, a schedule buffer protects against uncertainty that can affect the on-time completion of the project.

Reflecting Uncertainty in Estimates

The curve takes on this general shape because there normally is not much that can be done to accelerate the completion of a task, but there are an indefinite number of thins that can go wrong and delay the completion of a task.

The additional time between the 50% an the 90% estimate is called local safety.

We often add local safety to an estimate we want to be more confident of meeting.

Combining Buffers

When creating a release plan, our goal is to use buffers so that the team can make these types of commitments.

A Schedule Buffer Is Not Padding

I pad an estimate when I think it will take three days but I decide to tell you five, just in case.

A schedule buffer is a necessary margin of safety added to the sum of estimates from which local safety has been removed.

Some Caveats

You should not hide their existence or how they are used.

My Summary

Feature: Shopping list where you don't buy all the items

Schedule: To arrive before your flight departs you plan yours steps until your arrival, and then adds a buffer to ensure if anything goes wrong you can still make it.

Budget: Suppose you have thirty developers assigned to a project, but you have budget to allow up to thirty three developers.

The buffer should not be added at each task, it should be added to the overall project deadline. Adding the buffer to the overall project deadline, we will avoid the Parkinson's law ( work that expands to its maximum length).

Add buffers whenever you have a significant uncertainty or if the cost of being wrong is high. The buffers need to be communicated, and should not be hidden. If you are hiding buffers, most likely it's not a buffer and rather a padding.

Chapter 18 - Planning the Multiple-Team Project

Establishing a Common Basis for Estimates

At the start of a project, the teams should meet and choose between story points and ideal days. They should then establish a common baseline for their estimates so that an estimate by one team will be similar to that of another team if the other team had estimated the work instead.

The only time separate teams should consider estimating in different unit without a common baseline is when the products being built are truly separate and there is absolutely no opportunity for developer from one team to move onto another.

Adding Detail to User Stories Sooner

Ideally, an agile team begins an iteration with vaguely defined requirements and turns those vague requirements into functioning, tested software by the end of the iteration.

On a multiple team project, 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.

What I've found to be the most useful outcome of work done in advance of the iteration is the identification of the product owner's conditions of satisfaction for the user stories that are likely to be developed during the iteration.

Lookahead Planning

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 release plan then becomes a rolling lookahead plan that always outlines expectations about the new few iterations.

This is safer than planning on a handoff occurring during an iteration.

However, to the extent possible, they should limit commitments to work completed before the start of the iteration.

Incorporating Feeding Buffers into the Plan

consider including a feeding buffer, like the schedule buffer of the previous chapter.

This is, add a feeding buffer only if a team will be unable to do planned, high-priority work without the deliverables of another team.

A feeding buffer that is longer than an iteration is usually the result of planning to pass a large chunk of functionality on to another team.

My Summary

These might be requirements for bigger projects

• Establishing a common basis for estimates

  • (Worked together on a past project) Select user stories to represent the baseline
  • Collaboratively estimate user stories

• Adding detail to their user stories sooner

  • Find at least the satisfaction condition for most user stories

• Performing lookahead planning

  • Avoid handoff during iterations. Before the planning, try to identify dependencies between teams, and create a plan that accommodates all the user stories without handoffs during sprints. So if Team A is developing User Story 1 and Team B has the User Story 2 which depends on User Story 1. Create a plan where, Team B starts developing the User Story 2 the iteration after the Team A concludes User Story 1.

• Incorporating feeding buffers into the plan

  • When you cannot avoid handoffs, you can add a feeding buffer to make sure the commitments are going to be fulfilled. Make sure you only use as last option, since it adds duration for the project schedule.

Part V - Tracking and Communicating

Chapter 19 - Monitoring the Release Plan

Tracking the Release

First, and ideally most significant, is the amount of progress made by the team.

Second, however, is any change in the scope of the project.

... the developers may have learned things during the iteration that make them want to revise the story-point estimates assigned to some of the work coming later in the release plan.

Velocity

Velocity is expressed as the number of story points (or ideal days) completed per iteration.

The most important rule is that a team counts points towards velocity only for stories or features that are complete at the end of the iteration.

Complete means code that is well written, well factored, checked-in, and clean; complies with coding standards; and passes all tests.

(when US will not be completed during iteration) Usually, this means the story will be moved out of the iteration or split and parts of it moved out.

They wouldn't go so far as to accept a buggy untested version of the story, but they may reduce performance requirements, handling of special cases and so on.

The more work in process a team allows to build up, the longer it will take new features to be transformed from raw ideas into functioning software.

Release Burndown Charts

This becomes a powerful visual indicator of how quickly a team is moving toward its goal.

A Release Burndown Bar Chart

it's useful to draw the release burndown chart so that you can easily see the team's velocity and the scope changes separately.

• Any time work is completed, the top is lowered.
• When work is re-estimated, the top moves up or down.
• When new work is added, the bottom is lowered.
• When work is removed, the bottom is raised.

A Parking-Lot Chart

A parking-lot chart contains a large rectangular box for each theme (or grouping of user stories) in a release. Each box is annotated with the name of them, the number of stories in that theme, the number of story points or ideal days for those stories, and the percentage of the story points that are complete.

A parking-lot chart is a powerful method for compressing a great deal of information into a small space.

My Summary

Tracking the release of a project is important, because the project will change during its execution. Either because you had changes in scope, because you want to know where you are or because you learned and had to re-estimate your user stories.

Velocity is the rate of progress for agile teams. It measures the completed user stories from each iteration.

Why not consider unfinished work:

1. It's hard to measure unfinished or incomplete work.
2. Incomplete stories break down the trust between the developer team and the customer team on the project.
3. Unfinished work leads to a buildup of work in process in the development process. (Too much W.I.P).

Three types of charts:

1. Burndown chart: Simple. It does not differentiate changes in scope from velocity.
2. Burndown bar chart: Harder to understand. Differentiates velocity from changes in scope.
3. Parking-lot chart: Compresses a great deal of information.

Chapter 20 - Monitoring the Iteration Plan

The Task Board

A task board serves the dual purpose of giving a team a convenient mechanism for organizing their work and a way of seeing at a glance how much work is left.

(Working on one task) This helps maintain a consistent flow of work through the process and reduces the cost of context switching among multiple tasks.

Tracking Effort Expended

On a project, it is far more useful to know how much remains to be done rather than how much has been done.

tracking effort expended and comparing it with estimated effort can lead to "evaluation apprehension" (Sanders 1984).

Individual Velocity

Do not track individual velocity.

Individuals should be given every incentive possible to work as a team.

My Summary

• Task Board:

  • Organizes work
  • Visual

• Iteration Burndown Charts:

  • Same as release burndown chart
  • For iteration longer than one week.

Do not track expended effort, focus on how much remains to be done.

Do not track individuals velocity. It goes against a team spirit.

Chapter 21 - Communicating about Plans

We want all communication, but especially communication about estimates and plans, to be frequent, honest and two-way.

Plans are updated throughout the project, and these updates need to be comunicated.

If a developer knows that a given task will take much longer than currently expected, she needs to feel safe sharing that knowledge with the rest of the team, including her manager.

It is important that communication about estimating and planning be two-way, because we want to encourage dialogue and discussion about the plan so that we make sure we always have the best possible plan (given the current knowledge) for delivering value to the organization.

Communicating the Plan

When possible, include with your communication of a target date either your degree of confidence in the estimate, a range of possible dates, or both.

My Summary

Communication must be:

• Frequent
• Honest
• Two-way

For communicating dates use either a degree of confidence, a range of possible dates or both.

For communicating progress, because velocity fluctuates, consider:

• Last iteration's velocity
• Average velocity
• Average worst velocity ( slowest iterations)

You may use a end-of-iteration summary to sum up the communication. But, don't spend too much time on it.

Part VI - Why Agile Planning Works

Chapter 22 - Why Agile Planning Works

Planning is an attempt to find an optimal solution to the overall product development question: features, resources, and schedule.

While planning, we are exploring the entire spectrum of possible solutions of how to mix these three parameters such that we create the best product possible.

Re-planning Occurs Frequently

The release plan is updated either after each iteration or, at worst, after every few iterations. Acknowledging the impossibility of creating a perfect plan goes a long way toward reducing the anxiety that accompanies such a goal

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

An agile estimating and planning process recognizes that our knowledge is always incomplete and requires that plans be revised as we learn.

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.

To see the difference between estimates of size and duration, suppose I show you a book and ask you how long it will take you to read it. You can tell from its title that it’s a novel but I won’t let you look inside the book to see how many pages are in it, how wide the margins are, or how small the type is. To answer my question of how long it will take you to read this book, you first estimate the number of pages. Let’s assume you say 600. Then you estimate your rate of progress at one page per minute. You tell me it will take you 600 minutes or ten hours. In arriving at this estimate of duration (10 hours) you first estimated the size of the job (600 pages).

Plans Are Made At Different Levels

A team that works iteration to iteration without awareness of a more distant goal runs the risk of continually pursuing short-term goals while missing out on targeting a truly lucrative longer-term goal.

Plans Are Based On Features, Not Tasks

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

When planning by feature, the team has a much better understanding of the product

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.

One of the best ways to reduce variability is to work with reasonably small and similarly-sized units of work

Work In Process Is Eliminated Every Iteration

One of the reasons why agile planning succeeds is that all work in process is eliminated at the end of each iteration. Because work is not automatically rolled forward from one iteration to the next, each iteration is planned afresh.

This means a shorter feedback loop from users to the project team, which leads to faster learning a well as more timely risk mitigation and control.

Uncertainty Is Acknowledged And Planned For

When we create a plan early in a project and do not update the plan as we acquire new knowledge, we lose the opportunity to synchronize the plan with reality

A Dozen Guidelines for Agile Estimating and Planning

the whole team needs to be involved and committed to the pursuit of the highest-value project possible.

The best way to maintain a clear distinction between an estimate of size and one of duration is to use separate units that cannot be confused.

Be sure to include an expression of uncertainty in any release plan you produce.

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 (“We’ll be done on December 31 and the product will include at least these new features but probably no more than those other new features.”).

Use re-planning opportunities to ensure that the project is always targeted at delivering the greatest value to the organization.

Keep them informed by regularly publishing simple, very understandable indicators of the team’s progress.

As we learn more about our customers’ needs, new features are added to the project. As we learn more about the technologies we are using or about how well we are working as a team, we adjust expectations about our rate of progress and our desired approach

In addition to the value and cost of features when prioritizing consider also the learning that will occur and the risk that will be reduced by developing the feature.

My Summary

• Re-planning occurs frequently
• Estimate of size and duration are separated

• Plans are made at different levels

  • Conveys the reality needed for each level. Daily is precise, Iteration less precise, Release is the least precise.
  • Focus on short and long term
• Plans Are Based On Features, Not Tasks
• Small Stories Keep Work Flowing
• Work In Process Is Eliminated Every Iteration

• Tracking Is At The Team Level

  • Do not track Individual performance
• Uncertainty Is Acknowledged And Planned For

• A Dozen Guidelines for Agile Estimating and Planning

  • Involve the whole team
  • Plan at different levels
  • Keep estimates of size and duration separate by using different units
  • Express uncertainty in either the functionality or the date
  • Replan often
  • Track and communicate progress
  • Acknowledge the importance of learning
  • Plan features of the right size
  • Prioritize features
  • Base estimates and plans on facts
  • Leave some slack
  • Coordinate teams through lookahead planning

Part V - A Case Study

Chapter 23 - A case Study: Bomb Shelter Study

A big part of the benefit we’re after from trying an agile process requires everyone to participate

“The first form of the question is called the functional form, the second is the dysfunctional form. Asking it these two ways gives us a better answer than just asking ‘how much 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.

“I want to separate our features into three categories. First are features we must have. These are cost-of-entry features like saving and restoring games. The second category is features that the more we have of them, the better. I suspect things like playing levels will be in this category. The more playing levels, like strong, medium, and weak, the better. The third category are the exciters. These are features that most users don’t expect but once they see them, they want them. The right mix of features from the latter two categories plus all the necessary must-have features can add up to a compelling product"

Everyone agreed that the level of effort was just right—not too hard, not too soft, just right. Everyone committed that as a team they would deliver those three stories in two weeks.

“I’d prefer to give the estimate as a range. If we’re looking at enough work to go into an eighth iteration, we should probably say the project will take 6–10 iterations

My Summary

Shows in practice how the flow would work.