PEARL V: A Purview on Techniques for Estimation in Agile s/w Methodology

PEARL V: A Purview on Techniques for Estimation in Agile s/w Methodology

Estimation is one of the most misused elements in all of software development. Estimates should reflect the relative difficulty and length of work to guide planning and prioritization — not commit the team to mandatory Saturdays. With estimates in hand, stakeholders can make smart tradeoffs and reasonable forecasts.

Plans are only as good as the estimates, that the plans are based on, and estimates always come second to actual. The real world has this horrible habit of destroying plans.The customer has the right to an overall plan, to see progress and to be informed of schedule changes, Whereas the developer has the right to make and update his own estimates and to accept responsibility instead of having responsibility assigned to him.

You can’t put 10 pounds of groceries into a 5 pound bag. Forecasting tomorrow’s weather is much more difficult than telling what the weather was like yesterday.
Don’t try to be too sophisticated; estimates will never be anything other than approximate, however hard you try. Most software is not a predictable or mass manufacturing problem. Software development is new product development.

It is rarely possible to create upfront unchanging and detailed specs.Near the beginning, it is not possible to estimate. As empirical data emerge, it becomes increasingly possible to plan and estimate.Adaptive steps driven by build-feedback cycles are required. Creative adaptation to unpredictable change is the norm. Change rates are high.

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. we often need to expend just a fraction of that effort to get adequate results.

As effort on estimation increases, the accuracy may decrease after a certain amount of effort on estimation.

Vary the effort you put into estimating according to purpose of the estimate. if  the estimate will be used to make a software build versus buy decision, it is likely enough to determine that the project will take six to twelve months. It may be unnecessary to refine that to the point where you can say it will take seven or eight months.

First, no matter how much effort is invested, the estimate is never at the top of the accuracy that is 90 % to 100 %  accurate.No matter how much effort you put into an estimate, an estimate is still an estimate. No amount of additional effort will make an estimate perfect. It is possible to put too much effort into estimating, with the result being a less accurate estimate.

Agile teams, acknowledge that we cannot eliminate uncertainty from estimates, but they embrace the idea that small efforts are rewarded with big gains. Even though they are less far up the accuracy/effort scale, agile teams can produce more reliable plans because they frequently deliver small increments of fully working, tested, integrated code.


Contrasting Traditional and Agile Estimation Techniques

An average software project begins when a team or person outlines a project and receives approval to go forward. The project may be started by a product manager with an idea for an existing product, or by a customer request, or by the signing of a contract.

In the early stages of a project, someone guesses how long it will take to deliver. This person may be a salesperson, project manager, or development manager. They may make a guess based on their experience, or they may have some quick chats with seasoned employees and solicit their opinions.

When the timeline guess is in place, the project begins. If the project is related to a product, there may be marketing requirements to reference. If the project is for a customer, there may be a statement of work to reference. In either case, it’s common for an analyst team to convert the information into functional specifications.

After the functional specifications are completed, a conversation begins with the development team, designs begin to evolve, and some teams may document a technical design and architectural plan. When this work is complete, the development team provides estimates based on the anticipated approach. The team also estimates their capacity by resource type. Then the estimates, capacity, and known dependencies are entered into a project plan. At this point, the team has a schedule that they feel confident in, and they share it with the stakeholders.

This exercise may take several weeks or months to complete. If a project is timeboxed, the team may find that there isn’t enough time to deliver all the features for which they created functional specifications, designs, and estimates. The team then has to scope back the features for the project to meet the timeline, realizing they’ve wasted valuable time in estimating features that won’t be pursued.

Agile estimation techniques address the shortcomings of this method. You don’t design and estimate all your features until there has been a level of prioritization and you’re sure the features are needed. You used a phased approach to estimation, recognizing that you can be more certain as the project progresses and you learn more about the features.

At a high level, the phased process looks like this:

  1. Estimate the features in a short, time-boxed exercise during which you estimate feature size, not duration.
  2. Use feature size to assign features to iterations and create a release plan.
  3. Break down the features you assigned to the first iteration. Breaking down means identifying the specific tasks needed to build the features and estimating the hours required.
  4. Re-estimate on a daily basis during an iteration, estimating the time remaining on open tasks.

Agile estimating is also different in that you involve the entire team in the estimation process.

Whole Team Estimation

Every year, Best Buy Corporation tries to predict how many gift cards will be sold at Christmas. The typical process is to solicit the opinion of upper management and internal estimation experts to forecast a number.

In 2005, the CEO of Best Buy decided to try an experiment. The CEO followed the normal process for obtaining the estimates but also sent an email to approximately 100 random employees throughout the company, asking them how many gift cards they believed would be sold. The only information provided to both groups was the sales number for the previous year.

After the Christmas season was completed, the predictions of both groups were reviewed. The expert panel was accurate within 95 percent of the actual number of cards sold. The random group of employees was accurate within 99.9 percent of the number of cards sold . How did a random group beat the internal estimation experts?

In his book The Wisdom of Crowds, author James Surowiecki makes a case that a diverse set of independently thinking individuals can provide better predictions than a group of experts. Surowiecki qualifies this assertion by stating that the diversity needs to be in the way a group views problems and the heuristics each individual uses to analyze a problem or question. For example, a person’s age can greatly influence their perspective on an issue.

 Best Buy Corporation realized improved estimation accuracy by querying a large, diverse group of employees. The diverse set of employees consistently delivered better estimates than the in-house estimation experts.

Referenced Screen

Surowiecki’s work draws many parallels to the issues with estimating software development. We often get together a group of specialists or experts to estimate the work that needs to be completed. These experts may be managers or leads who facilitate the work of their various teams. The fact that all the experts may be a part of management limits their diversity in opinion. And the fact that these experts may work together frequently may lead to standardized thinking, also known as groupthink.

In an Agile environment, you increase the accuracy of your feature estimates by estimating the features together as a team. Estimates aren’t limited to managers or leads but also include developers, testers, analysts, DBAs, and architects. The features are viewed from various perspectives, and you merge these perspectives to create a common, agreed-on estimate.

Entire-team estimation has additional benefits beyond diverse opinion. First, you get estimates from people who are closer to the work. Team members’ opinions may be diverse, but they provide better estimates because they know your existing code, architecture, and domains and what it takes to deliver in your environment.

A second benefit is team ownership of the estimate. If a manager provides the estimate, they hope the team supports the estimate and buys into it. If the team provides the estimate, they’re immediately closer to owning the estimate, and they feel more responsible for making the dates they provided.

Moving to team-based estimation isn’t easy. Managers may not welcome additional input, and team members may be reluctant to challenge the experts and instead echo whatever the experts say.

It will take time to overcome these hurdles, but you can do one thing to expedite the change: when you perform team-based estimation, have the meeting facilitated by an indirect manager such as a project manager or ScrumMaster. This person can treat all people as equals regardless of title and proactively query team members who are reluctant to contribute. You can also use the planning poker process discussed in the next section to prevent one person’s estimate from influencing another’s.

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), estimates are best derived collaboratively by the team, which includes those who will do the work. There are two reasons for this.

Size of story is given in “story points” (an abstract unit). The team defines how  a story point translates to effort (typically: 1 story point = 1 ideal day of work). ƒ The number of story points that a team can deliver in an iteration is called  “team velocity”.

Agile Estimation

There are three main concepts  team need to understand to do agile estimation,

  • Estimation of Size gives a high-level estimate for the work item, typically measured using a neutral unit such as story points
  • Velocity tells us how many points this project team can deliver within an iteration;
  • Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take the team member(s) to complete the assigned work item(s).

Estimation of Size

Story Points is a relative measure that can be used for agile estimation of size. The team decides how big a story point is, and based on that size, determines how many story points each work item is. To make estimation go fast, use only full story points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 story points. To get started, look at 10 or so representative work items, give the smallest the size of one story point, and then go through all other work items and give them a relative story point estimate based on that story point. Note that story points are used for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to avoid wasting effort on things that are unlikely to be addressed within the current iteration.

A key benefit of story points is that they are neutral and relative. Let’s say that Ann is 3 times more productive than Jack. If Ann and Jack agree that work item A is worth 1 story point, and they both think work item B is roughly 5 times as big, they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours, while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use Velocity to determine how much ‘size’, or how many points, the team can take on within an iteration.

One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project. Make sure that the entire team is involved in assessing size, or at least that the same people are involved in all your size estimates, to ensure consistency within your project. We will see how the concept of velocity will fix also this discrepancy in a point meaning different things to different project teams.

You can also use other measures of size, where the most common alternative is Ideal Days.


Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a certain team and project. As an example, a team planned to accomplish 20 points in the first iteration. At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence 14. For the next iteration, they may plan for fewer points, let’s say 18 points, since they think they can do a little better than in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.

Expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and points are not always identical in terms of effort. Some team members are more effective than others, and some problems end up being harder than others. Also, changes to the team structure, learning new skills, changes to the tool environment, better teaming, or more overhead with meetings or tasks external to the project will all impact velocity. In general, velocity typically increases during the project as the team builds skills and becomes more cohesive.

Velocity compensates for differences between teams in terms of how big a point is. Let’s assume that project team Alpha and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team Alpha, however, assesses all work items as being worth 3 times as many points as team Beta’s estimates. Team Alpha assesses work item A, B, C, and D to correspond to 30 points, and team Beta estimates the same work items to correspond to 10 points. Both teams deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and team Beta a velocity of 10. It may sound as if team Alpha is more effective, but let’s look at what happens when they plan the next iteration. They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and team Beta as normal has estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many points as indicated by their velocity, they can both take on all of E-H. The end result is that it does not matter how big a point is, as long as you are consistent within your team.

Velocity also averages out the efficiency of different team members. Let’s look at an example; Let’s assume that Ann always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3 points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on. As you switch team members, or as team members become more or less efficient, your velocity will change, and you can hence take on more or less points. This does however not require you to change the estimate of the size. The size is still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand for that iteration.

Estimation of Effort

Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the units of Actual Days or Actual Hours. As you plan an iteration, you will take on a work item, such as detail, design, implement and test a scenario, which may be sized to 5 points. Since this is still a reasonably big work item, break it down into a number of smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and Testing Server portion, and Implementing and Testing Client portion of the scenario. Team members are asked to sign up for the tasks, and then detail the estimate of the actual effort, measured in hours or days, for their tasks. In this case, the following actual estimates were done (with person responsible within parenthesis):

  • Detailing scenario (Ann): 4 hours
  • Designing scenario (Ann and Jack):  6 hours
  • Implementing and Testing Server portion of scenario (Jack): 22 hours
  • Implementing and Testing Client portion of scenario (Ann): 12 hours
  • Total Effort Estimate for Scenario: 44 hours

If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often, some level of analysis and design of the work item needs to take place before a reasonable estimate can be done. Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to re-estimate the effort required to complete the task, so we have a realistic view of progress within an iteration.

First, on an agile project we tend not to know specifically who will perform a given task. Yes, we may all suspect that the team’s database guru will be the one to do the complex stored procedure task that has been identified. However, there’s no guarantee that this will be the case. S/he may be busy when the time comes, and someone else will work on it. So because anyone may work on anything, it is important that everyone have input into the estimate. Second, even though we may expect the database guru to do the work, others may have something to say about her estimate. Suppose that the team’s database guru, Kristy, estimates a particular user story as three ideal days. Someone else on the project may not know enough to program the feature himself, but he may know enough to say, “Kristy, you’re nuts; the last time you worked on a feature like that, it took a lot longer. I think you’re forgetting how hard it was last time.” At that point Kristy may offer a good explanation of why it’s different this time. However, more often than not she will acknowledge that she was indeed underestimating the feature.

The Estimation Scale Studies have shown that we are best at estimating things that fall within one order of magnitude (Miranda 2001; Saaty 1996). Within your town, you should be able to estimate reasonably well the relative distances to things like the nearest grocery store, the nearest restaurant, and the nearest library. The library may be twice as far as the restaurant, for example.  Because we are best within a single order of magnitude, we would like to have most of our estimates in such a range. Two estimation scales are of good success

which are

◆ 1, 2, 3, 5, and 8

◆ 1, 2, 4, and 8

There’s a logic behind each of these sequences. The first is the Fibonacci sequence. Agilists found this to be a very useful estimation sequence because the gaps in the sequence become appropriately larger as the numbers increase. A one- point gap from 1 to 2 and from 2 to 3 seems appropriate, just as the gaps from 3 to 5 and from 5 to 8 do. The second sequence is spaced such that each number is twice the number that precedes it. These nonlinear sequences work well because they reflect the greater uncertainty associated with estimates for larger units of work. Either sequence works well, although  preference is for the first. 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. If you are estimating using 1, 2, 3, 5, and 8, and have a story that you think is just the slightest bit bigger than the other five-point stories you’ve estimated, it would be OK to put it into the five-point bucket.

A story you think is a 7, however, clearly would not fit in the five-point bucket.You may want to consider including 0 as a valid number within your estimation range. Although it’s unlikely that a team will encounter many user stories or features that truly take no work, including 0 is often useful. There are two reasons for this. First, if we want to keep all features within a 10x range, assigning nonzero values to tiny features will limit the size of largest features. Second, 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. If the team earns one point in this iteration for something truly trivial, in the next iteration their velocity will either drop by one or they’ll have to earn that point by doing work that may not be as trivial. If the team does elect to include 0 in their estimation scale, everyone involved in the project (especially the product owner) needs to understand that 13 × 0 ≠ 0 .

 Agilists 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. An alternative to using 0 is to group very small stories and estimate them as a single unit. Some teams prefer to work with larger numbers, such as 10, 20, 30, 50, and 100. This is fine, because these are also within a single order of magnitude. However, if you go with larger numbers, such as 10 to 100, Agilists still recommend that you pre-identify the numbers you will use within that range. Do not, for example, allow one story to be estimated at 66 story points or ideal days and another story to be estimated at 67. That is a false level of precision, and we cannot discern a 1.5% difference in size. It’s acceptable to have one-point differences be-tween values such as 1, 2, and 3. As percentages, those differences are much larger than between 66 and 67.

User Stories, Epics, and Themes

3-tier story sizing estimation is a great approach when managing work from the Portfolio to Program to Project level. Corporate initiatives (investment themes) are implemented by Features. These are coarse grain, high level items used for Product Road Mapping and the Story Point sizing is a very rough estimate of the total effort. As Features get broken down into Epics and then stories, each progressive refinement results in more granular Story Points estimates that can be used for Release and Sprint Planning.

Although in general, we want to estimate user stories whose sizes are within one order of magnitude, this cannot always be the case. If we are to estimate every-thing within one order of magnitude, it would mean writing all stories at a fairly fine-grained level.

For features that we’re not sure we want (a preliminary cost estimate is desired before too much investment is put into them) or for features that may not happen in the near future, it is often desirable to write one much larger user story.

A large user story 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.

An epic, by its very size alone, is often a theme on its own. By aggregating some stories into themes and writing some stories as epics, a team is able to reduce the effort they’ll spend on estimating. 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.

User stories that will be worked on in the near future (the next few iterations) need to be small enough that they can be completed in a single iteration. These items should be estimated within one order of magnitude. Agilists use the sequence 1, 2, 3, 5, and 8 for this. User stories or other items that are likely to be more distant than a few iterations can be left as epics or themes. These items can be estimated in units beyond the 1 to 8 range. To accommodate estimating these larger items Agilists add 13, 20, 40, and 100 to preferred sequence of 1, 2, 3, 5, and 8.

Deriving an Estimate The three most common techniques for estimating are

◆ Expert opinion

◆ Analogy

◆ Disaggregation

Each of these techniques may be used on its own, but the techniques should be combined for best results.

Expert Opinion

If you want to know how long something is likely to take, ask an expert. At least, that’s one approach. In an expert opinion-based approach to estimating, an expert is asked how long something will take or how big it will be. 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. Developing this functionality is likely to require a variety of skills normally performed by more than one person. This makes it difficult to find suitable experts who can assess the effort across all disciplines. On a traditional project for which estimates are associated with tasks, this is not as significant of a problem, because each task is likely performed by one person. A nice benefit of estimating by expert opinion is that it usually doesn’t take very long. Typically, a developer reads a user story, perhaps asks a clarifying question or two, and then provides an estimate based on her intuition. There is even evidence that says this type of estimating is more accurate than other, more analytical approaches (Johnson et al. 2000).


An alternative to expert opinion comes in the form of estimating by analogy, which is what we’re doing when we say, “This story is a little bigger than that story.” When estimating by analogy, the estimator compares the story being estimated with one or more other stories. If the story is twice the size, it is given an estimate twice as large. There is evidence that we are better at estimating relative size than we are at estimating absolute size (Lederer and Prasad 1998; Vicinanza et al. 1991). When estimating this way, you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated. This is referred to as triangulation. To triangulate, compare the story being estimated against a couple of other stories. To decide if a story should be estimated at five story points, see if it seems a little bigger than a story you estimated at three and a lit- tle smaller than a story you estimated at eight.


Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces. If most of the user stories to be included in a project are in the range of two to five days to develop, it will be very difficult to estimate a single story that may be 100 days. Not only are large things notoriously more difficult to estimate, but also in this case there will be very few similar stories to compare. Asking “Is this story fifty times as hard as that story” is a very different question from “Is this story about one-and-a-half times that one?” The solution to this, of course, is to break the large story or feature into multiple smaller items and estimate those. However, you need to be careful not to go too far with this approach. Not only does the likelihood of forgetting a task increase if we disaggregate too far, but summing estimates of lots of small tasks also leads to problems.

Planning Poker

The best way Agilists have found for agile teams to estimate is by playing planning poker (Grenning 2002). Planning poker combines expert opinion, analogy, and disaggregation into an enjoyable approach to estimating that results in quick but reliable estimates. Participants in planning poker include all of the developers on the team. Remember that developers refers to all programmers, testers, database engineers, analysts, user interaction designers, and so on. On an agile project, this will typically not exceed ten people. If it does, it is usually best to split into two teams. Each team can then estimate independently, which will keep the size down. The product owner participates in planning poker but does not estimate. At the start of planning poker, each estimator is given a deck of cards. Each card has written on it one of the valid estimates.

Each estimator may, for example, be given a deck of cards that reads 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. The cards should be prepared prior to the planning poker meeting, and the numbers should be large enough to see across a table. Cards can be saved and used for the next planning poker session.

For each user story or theme to be estimated, a moderator reads the description. The moderator is usually the product owner or an analyst. However, the moderator can be anyone, as there is no special privilege associated with the role. The product owner answers any questions that the estimators have. The goal in planning poker is not to derive an estimate that will withstand all future scrutiny.

Rather, the goal is to be somewhere well on the left of the effort line, where a valuable estimate can be arrived at cheaply. After all questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection. At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate. It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates. It’s important that this does not come across as attacking those estimators. Instead, you want to learn what they were thinking about.

As an example, the high estimator may say, “Well, to test this story, we need to create a mock database object. That might take us a day. Also, I’m not sure if our standard compression algorithm will work, and we may need to write one that is more memory efficient.” The low estimator may respond, “I was thinking we’d store that information in an XML file—that would be easier than a database for us. Also, I didn’t think about having more data—maybe that will be a problem.”

The group can discuss the story and their estimates for a few more minutes. The moderator can take any notes she thinks will be helpful when this story is being programmed and tested. After the discussion, each estimator re-estimates by selecting a card. Cards are once again kept private until everyone has estimated, at which point they are turned over at the same time. In many cases, the estimates will already converge by the second round. But if they have not, continue to repeat the process. The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together. It isn’t necessary that everyone in the room turns over a card with exactly the same estimate written down.

Again, the point is not absolute precision but reasonableness.

Smaller Sessions 

It is possible to play planning poker with a subset of the team, rather than involving everyone. This isn’t ideal but may be a reasonable option, especially if there are many, many items to be estimated, as can happen at the start of a new project. The best way to do this is to split the larger team into two or three smaller teams, each of which must have at least three estimators. It is important that each of the teams estimates consistently.

What your team calls three story points or ideal days had better be consistent with what other team calls the same. To achieve this, start all teams together in a joint planning poker session for an hour or so. Have them estimate ten to twenty stories. Then make sure each team has a copy of these stories and their estimates and that they use them as base-lines for estimating the stories they are given to estimate.

When to Play Planning Poker

Teams will need to play planning poker at two different times. First, there will usually be an effort to estimate a large number of items before the project officially begins or during its first iterations.

Estimating an initial set of user stories may take a team two or three meetings of from one to three hours each. Naturally, this will depend on how many items there are to estimate, the size of the team, and the product owner’s ability to clarify the requirements succinctly. Second, teams will need to put forth some ongoing effort to estimate any new stories that are identified during an iteration. One way to do this is to plan to hold a very short estimation meeting near the end of each iteration. Normally, this is quite sufficient for estimating any work that came in during the iteration, and it allows new work to be considered in the prioritization of the coming iteration.

Alternatively, Kent Beck suggests hanging an envelope on the wall with all new stories placed in the envelope. As individuals have a few spare minutes, they will grab a story or two from the envelope and estimate them. Teams will establish a rule for themselves, typically that all stories must be estimated by the end of the day or by the end of the iteration.

Agilists like the idea of hanging an envelope on the wall to contain unestimated stories. However, they prefer that when someone has a few spare minutes to devote to estimating, he find at least one other person and that they estimate jointly.

Why Planning Poker Works

it’s worth spending a moment on some of the reasons why it works so well. First, planning poker brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else.

After completing a thorough review of the literature on software estimation, Jørgensen (2004) concluded that “the people most competent in solving the task should estimate it.” Second, a lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates. This has been found to improve the accuracy of the estimate, especially on items with large amounts of un-certainty (Hagafors and Brehmer 1983).

Being asked to justify estimates has also been shown to result in estimates that better compensate for missing information (Brenner et al. 1996). This is important on an agile project because the user stories being estimated are often intentionally vague. Third, studies have shown that averaging individual estimates leads to better results (Hoest and Wohlin 1998) as do group discussions of estimates (Jørgensen and Moløkken 2002). Group discussion is the basis of planning poker, and those discussions lead to an averaging of sorts of the individual estimates.

Finally, planning poker works because it’s fun.Expending more time and effort to arrive at an estimate does not necessarily increase the accuracy of the estimate. The amount of effort put into an estimate should be determined by the purpose of that estimate. Although it is well known that the best estimates are given by those who will do the work, on an agile team we do not know in advance who will do the work.

Therefore, estimating should be a collaborative activity for the team. Estimates should be on a predefined scale. Features that will be worked on in the near future and that need fairly reliable estimates should be made small enough that they can be estimated on a nonlinear scale from 1 to 10 such as 1, 2, 3, 5, and 8 or 1, 2, 4, and 8. Larger features that will most likely not be implemented in the next few iterations can be left larger and estimated in units such as 13, 20, 40, and 100. Some teams choose to include 0 in their estimation scale. To arrive at an estimate, we rely on expert opinion, analogy, and disaggregation.

A fun and effective way of combining these is planning poker. In planning poker, each estimator is given a deck of cards with a valid estimate shown on each card. A feature is discussed, and each estimator selects the card that represents his or her estimate. All cards are shown at the same time. The estimates are discussed and the process repeated until agreement on the estimate is reached.

Planning for Iterations

During project planning, iterations are identified, but the estimates have an acceptable uncertainty due to the lack of detail at the project inception. This task is repeated for each iteration within a release. It allows the team to increase the accuracy of the estimates for one iteration, as more detail is known along the project.

Ensure that the team commits to a reasonable amount of work for the iteration, based on team performance from previous iterations. Prioritize the work items list before you plan the next iteration. Consider what has changed since the last iteration plan (such as new change requests, shifting priorities of your stakeholders, or new risks that have been encountered).

When the team has decided to take on a work item, it will assign the work to one or several team members. Ideally, this is done by team members signing up to do the work, since this makes people motivated and committed to doing the job. However, based on your culture, you may instead assign the work to team members.

Wall Estimation

Planning poker is a fantastic tool for estimating user stories, but it would take an inordinate amount of time to estimate hundreds of stories, one at a time, using planning poker. If you have a raw backlog filled with hundreds of stories that have not been estimated or prioritized, you’re going to need a faster way to estimate.

Wall Estimation is designed to allow teams to eliminate discussions of 2 versus 3 and 5 versus 8 and instead group things in a purely relative manner along a continuum, at least initially. It also allows stakeholders to give a general prioritization to a large group of stories without getting hung up on whether one story is slightly more important than another.

Example Wall Estimation - Relative Sort

To do Wall Estimation, you must first print your user stories on cards. Then gather your team and stakeholders in a room with a big empty wall (about 14 feet long by 8-10 feet high); Understand two things about the wall:

  • Height determines priority. Stories at the top are higher; stories at the bottom are lower. A story’s priority can be based on ROI, business value, or something as simple as “it’s just important, and I don’t know why.”

  • Width is reserved for size. Stories on the left are smaller; stories on the right are bigger. (You can reverse this and move from right to left if you’re in, say, Japan and it’s more logical.) The important thing is to envision a line going horizontally and one going vertically. Team members and stakeholders should ask themselves, where, relative to the other stories, does this one fit?

The team will use the wall to size all of the stories. The stakeholders will use the wall to prioritize stories. As with planning poker, we’re using relative sizing, but instead of using two reference stories for comparison, the wall becomes the constant. Small story? Move to the left. Big story? Move to the right. Important story? Place it high. A story that we can live without for now? Place it low.

Although the stakeholders do not have to be there while the stories are being estimated, the team does need to be in the room while the stories are being prioritized. The ScrumMaster and product owner must attend both the estimation and prioritization activities.


Although  customers and stakeholders will want to know how big a story is to help them determine its priority, they’ll be much more focused on finding the stories that relate to them and making sure those stories get done. Expect your stakeholders to disagree about priority—your product owner will use this information to help decide the ultimate priority.

Ask the stakeholders to help determine the relative priority of all of these stories by moving these stories up or down inside the taped columns. Remind them that the higher up a story is on the wall, the higher its priority to the business. Set the following rules:

  • If you place a story at the top, be prepared to justify the placement.
  • You may ask each other why one story is more important than another. Feel free to ask each other, “Who moved this one down (or up)?” or to say aloud, “I think this one needs to move. Who wants to disagree?” This enables conversation between the interested parties, without facilitation.
  • If you move a story lower on the wall than someone else did, mark it with a colored dot to alert us.

The biggest benefit to prioritizing as a group is that all the stakeholders can better understand the priorities of various stories. If a discussion goes on too long without resolution, the product owner should collect the card, identify the two stakeholders who cannot agree, and make a note to meet with them privately later.

The exercise could take 2-6 hours, depending on the number of stories and the number of stakeholders. When you are finished, the wall will look something like the picture shown below.

Example Wall Estimation - Priority SortYour wall will break down roughly into four quadrants. The stories in the top left are high priority and small so they’ll end up in the top of the product backlog. The stories in the top right are high priority but are also large. These stories should be broken down soon so they can be brought into upcoming sprints.

Wall Estimation - Four QuadrantsThe lower left quadrant is made up of small stories that are lower in priority. They will likely fall to the bottom of the backlog. The lower right quadrant is filled with large stories that are also lower in priority. These stories are your epics or themes. They’ll eventually need to be broken down into smaller, more manageable stories but not until they rise in priority.

Spend some time looking at the wall as a whole with the group. If a story is in the wrong quadrant, move it. If a high-priority story must be broken down and time allows, do it while everyone is in the room.

At the end of wall estimation, you’ll have the start of a release plan. If you know the team’s historical velocity, you can even supply a rough range of which stories in the upper-left quadrant will be finished.

Estimation is hard because there is so much uncertainty at the beginning of a project. Product Owners and agile project managers try to maximize value early learning by having conversations with their product owners and stakeholders, producing working software, and integrating feedback about that software to get to a releasable state. But even agile projects must provide some estimate of when a set of features will be ready for release.

Quadrus Estimation Methodology

Quadrus is a recognized leader in IT professional services and solutions. Headquartered in Calgary, Alberta, Quadrus has delivered hundreds of successful projects across Western Canada since 1993. They are committed to providing the highest quality service to valued clients.

Quadrus has developed the Quadrus Estimation Methodology which is different for a few key reasons:
QEM recognizes that way in which people estimate – and when forming overall project estimates, QEM employs Monte-Carlo simulation to aggregate individual estimates in a statistically correct  way.
QEM takes into account those project tasks that are often left out of  project estimates. Activities such as requirements clarification, task  management and coordination, meetings, demos, testing and deployment are all included in the project estimate.
QEM recognizes that often not all project requirements are known  up front. QEM provides a mechanism for estimating the percentage of  known requirements (versus the percentage of unknown requirements), and the overall project estimate is appropriate scaled to  reflect the reality of unknown requirements.
QEM recognizes that most people naturally create single-point estimates for tasks or stories – and QEM is able to work with these (less-than-perfect) estimates. The input to QEM consists, quite simply, of the single-point estimate that the developer feels is the most intuitive estimate (the median) together with an uncertainty factor (Low, Medium or High) to indicate the range of the distribution curve to use. If a task seems to have many unknowns or perhaps uses new technologies – or if it may have an element of research or invention – then the uncertainty will be higher than a task that is known and recognized (lower uncertainty).
This uncertainty is very important; recognizing it exists can drastically change how much time we should assume a task can take. One story may have a lower numeric estimate than another but with a greater level of uncertainty could actually end up taking more time.
These inputs are not onerous to produce compared to the inputs demanded by other estimation methodologies that have been tried in the past (e.g., feature points, estimated lines of code, etc.). Together the single-point estimate/uncertainty pair provides enough information to calculate an expected average estimate for the individual story together with a range.

Quadrus has codified the Quadrus Estimation Methodology as a modern AJAX-powered, intuitive and easy to use web application named the Quadrus Estimator. The Quadrus Estimator has many features, such as support for the user-story importance to be ranked using a star-rating and enabling stories to be labeled. The star-rating and labels can be used to manage and filter the list of tasks and also to include or exclude stories from an estimate for “what-if” scenarios based on less important stories or certain features being postponed for future phases.
The simulation also accepts additional inputs to allow additional effort to be counted for which is often overlooked when creating estimates. This is in the form of “Story Glue” to represent non-development time that is still project related and must be accounted for (e.g., meetings, writing reports, demos, etc.).

The Quadrus Estimator calculates the total effort to complete the project in man-months. Along with the effort estimate, a combination of proven industry guidelines and research is applied to identify the ideal balance between resources (people) and duration (timescale). While either can be adjusted in the Estimator, the system shows the cost of favoring the other in terms of additional effort (overall cost), more resources (for faster delivery), or longer timescales (for team-size constraints).

PEARL IV : INVEST in good User Stories and SMART Tasks

PEARL IV : INVEST in good User Stories and SMART Tasks

In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard.

User stories originated with Extreme Programming (XP), whose first written description in 1998 only claimed that customers defined project scope “with user stories, which are like use cases”. Rather than offered as a distinct practice, they were described as one of the “game pieces” used in the planning game. However, most of the further literature thrust around all the ways arguing that user stories are “unlike” use cases, in trying to answer in a more practical manner “how requirements are handled” in XP and more generally Agile projects. This drives the emergence, over the years, of a more sophisticated account of user stories.

In 2001, Ron Jeffries proposed the well-known Three C’s formula, i.e. Card, Conversation, Confirmation, to capture the components of a user story:

A Card (or often a Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstraction;

A Conversation is taking place at different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation;

The Confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally.

A pidgin language is a simplified language, usually used for trade, that allows people who can’t communicate in their native language to nonetheless work together. User stories act like this. We don’t expect customers or users to view the system the same way that programmers do; stories act as a pidgin language where both sides can agree enough to work together effectively.

User stories are written by or for business users or customers as a primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), though primarily it is the task of a product manager to ensure user stories are captured.

Agile projects, especially Scrum , use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.

It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

When the time comes for creating user stories, one of the developers gets together with a customer representative, e.g. a product manager (or product owner in Scrum), which has the responsibility for formulating the user stories. The developer may use a series of questions to get the customer representative going, such as asking about the desirability of some particular functionality, but must take care not to dominate the idea-creation process.


A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.

As the customer representative conceives a user story, it is written down on a note card (e.g. 3×5 inches or 8×13 cm) with a name and a brief description. If the developer and the customer representative find a user story deficient in some way (too large, complicated, or imprecise), it is rewritten until satisfactory – often using the INVEST guidelines. Commonly, user stories are not to be definite once they have been written down, since requirements tend to change throughout the development lifecycle, which agile processes handles by not carving them in stone upfront.

A Scrum epic is a large user story. There’s no magic threshold at which we call a particular story an epic. It just means “big user story.

“Theme” is a collection of user stories

Important considerations for writing user stories:

  1. Stakeholders write user stories. An important concept is that your project stakeholders write the user stories, not the developers. User stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the stakeholders) write them. As its name suggests, a user story describes how a customer or a user employs the product. You should therefore tell the stories from the user’s perspective.
  2. Personas : A great way to capture your insights about the users and customers is to use personas. But there is more to it: The persona goals help you discover your stories. Simply ask yourself: What functionality does the product have to provide to meet the goal of the personas.A user persona is a representation of the goals and behavior of a hypothesized group of users. In most cases, personas are synthesized from data collected from interviews with users. They are captured in 1–2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.
  3. Use the simplest tool : User stories are often written on index cards as you see in Figure 2(below)  Index cards are very easy to work with and are therefore an inclusive modeling technique.
  4. Remember non-functional requirements: Stories can be used to describe a wide variety of requirements types. For example in Figure 1(below) the Students can purchase parking passes online user story is a usage requirement similar to a use case whereas the Transcripts will be available online via a standard browser is closer to a technical requirement.
  5. Indicate the estimated size: You can see in Figure 2 that it includes an estimate for the effort to implement the user story. One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2.5 hours per point; therefore the user story in Figure 2 will take around 10 hours to implement.
  6. Indicate the priority: Requirements, including defects identified as part of your independent parallel testing activities or by your operations and support efforts, are prioritized by your project stakeholders (or representatives thereof such as product owners) and added to the stack in the appropriate place. You can easily maintain a stack of prioritized requirements by moving the cards around in the stack as appropriate. You can see that the user story card includes an indication of the priority; Agilists often use a scale of one to ten with one being the highest priority. Other prioritization approaches are possible – priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card it’s own unique priority order number (e.g. 344, 345, …). You want to indicate the priority somehow in case you drop the deck of cards, or if you’re using more sophisticated electronic tooling. Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack. The implication is that your prioritization strategy needs to support this sort of activity. The advice is to keep it simple.
  7. Optionally include a unique identifier: The card also includes a unique identifier for the user story, in this case 173. The only reason to do this would be to do this is if you need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.

Figure 1. Example user stories.

  • Students can purchase monthly parking passes online.
  • Parking passes can be paid via credit cards.
  • Parking passes can be paid via PayPal.
  • Professors can input student marks.
  • Students can obtain their current seminar schedule.
  • Students can order official transcripts.
  • Students can only enroll in seminars for which they have prerequisites.
  • Transcripts will be available online via a standard browser.

Figure 2. User story card (informal, high level).


A team at Connextra developed the traditional user-story template in 2001:

“As a <role>, I want <goal/desire> so that <benefit>”

Mike Cohn, a well-known author on user stories, regards the “so that” clause as optional:

“As a <role>, I want <goal/desire>”

Chris Matts suggested that “hunting the value” was the first step in successfully delivering software, and proposed this alternative as part of Feature Injection:

“In order to <receive benefit> as a <role>, I want <goal/desire>”

Another template based on the Five Ws specifies:

“As <who> <when> <where>, I <what> because <why>.”

User Scenarios

A user scenario expands upon your user stories by including details about how a system might be interpreted, experienced, and used. Like user stories, you might imagine several scenarios for each persona group that you anticipate will make up your audience. Your scenarios should anticipate the user’s goal, specify any assumed knowledge, and speculate on the details of the user’s interaction experience.

User Stories and Planning

There are two areas where user stories affect the planning process on agile projects:

  1. Scheduling. In the agile change management management process where work items, including stories, are addressed in priority order. So, the implication is that the priority assigned to a story affects when the work will be done to implement that requirement. Project stakeholders are responsible for prioritizing requirements.  A numerical prioritization strategy is taken (perhaps on a scale of 1 to 20) and a MoSCoW (Must Should Could Won’t) approach is also used. Stakeholders also have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, stakeholders must also be responsible for making decisions and providing information in a timely manner.
  2. Estimating. Developers are responsible for estimating the effort required to implement the things which they will work on, including stories. The implication is that because you can only do so much work in an iteration, the size of the work items (including stories), affect when those work items will be addressed. Although you may fear that developers don’t have the requisite estimating skills, and this is often true at first, the fact is that it doesn’t take long for people to get pretty good at estimating when they know that they’re going to have to live up to those estimates. If you’ve adopted the pair programming practice then a user story must be able to be implemented by two people in a single iteration/sprint. Therefore if you’re working in one week iterations each user story must describe less than one week worth of work. Of course, if you aren’t taking a non-solo development approach such as pair programming the user story would need to be implementable by a single person within a single iteration. Large stories, sometimes called epics, would need to be broken up into smaller stories to meet this criteria.


Bill Wake  introduced the INVEST mnemonic in his seminal post on creating better stories, suggesting they should be Independent, Negotiable, Valuable, Estimable, Small, and Testable. An acute observer of common disconnects between product people and developers, his mnemonic remains an excellent checklist for the creation of high quality product design inputs.

The acronym “INVEST” can remind you that good stories are:

I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable


Ideally, you should be able to implement your stories in any order while still realizing the benefit of seeing something working at the end. This is important for two reasons. First, you lose a lot of the adaptability agile’s supposed to deliver if your stories have (many) interdependencies. Second, it makes it much more likely you’ll end up at the end of an iteration without working product that you can validate to make sure that you’re moving in a valuable direction.

Negotiable… and Negotiated

User stories are not requirements A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.They’re not another just another template to put on a piece of paper- they’re part of a process where the product person (original drafter) of the stories co-creates a working incarnation of the story with the implementer. This way, the original author gets someone to help them improve/”edit” their story and make sure the story’s interpreted into product in a way that delivers on something Valuable for the user.


A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.

This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

Making each slice valuable to the customer supports XP’s pay-as-you-go attitude toward infrastructure.

Stories want to communication information. Don’t hide them on a network drive, the corporate intranet , or a licensed tool. Make them visible instead, for instance, by putting them up on the wall. A great tool to discover, visualize, and manage your stories is a Product Canvas pasted on the wall.


A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)

It should be possible for a developer with relevant experience to roughly estimate a story. That estimate’s then used by the product person to prioritize their list of stories, taking account of both value and cost (in terms of developer time).


„ Large stories (epics) are

– hard to estimate
– hard to plan

They don’t fit well into single sprints
„ Compound story

– An epic that comprises multiple shorter stories

„ Complex story

– A story that is inherently large and cannot easily be  disaggregated into constituent stories

Compound stories sometimes hide assumptions, Split compound stories along operational boundaries (CRUD), Data Boundaries.

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.

Detail can be added to user stories in two ways:

  • By splitting a user story into multiple, smaller user stories.
  • By adding “conditions of satisfaction.”

When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added. After all, more has been written.

The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user story is complete

Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights.

A story map is a graphical, two-dimensional product backlog. At the top of the map are big user stories, which are sometimes “epics” as Mike Cohn describes them, and other times correspond to “themes” or “activities”. These grouping units are created by orienting at the user’s workflow or “the order you’d explain the behavior of the system”. Vertically, below the epics, the actual story cards are allocated and ordered by priority. The first horizontal row is a “walking skeleton” and below that represents increasing sophistication.

In this way it becomes possible to describe even big systems without losing the big picture.


A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.

Strive for 90% Test Automation.

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.

A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figure out how to operationalize these tests will help the team learn the true needs.

For all these attributes, the feedback cycle of proposing, estimating, and implementing stories will help teach the team what it needs to know.

 Agile User Stories Prioritization 

Aim of Agile User Stories Prioritization  engineering actions are to contribute to business value that is described in terms of return-on investment of software product and it is very  essential for a software. For a product to be  successful, it is very important to identify the  correct equalizer among the competing quality  User Stories. From the customers’ view, the action  of continuous User Stories prioritization creates  the very core of today’s agile process

Continuous requirements prioritization  process from the customer‟s scope of vision forms the  essential of today‟s agile approaches. An essential  feature of any agile approach is an expressed focus on  making business value for the customer . Agile software process practitioners deem this approach  especially valuable for the software producers in a  circumstance that admits extremely uncertain requirements, experimentation with fresh  development technology, and customers willing to  explore the ways in which developing product can  assist their business goals.

The continuous  prioritization of requirements during the project acts  as fundamental role in accomplishing business value  creation. Requirements (re)prioritization at interiteration time is the means to align expert decisions to  the business strategy that aims the business value.

Creating a great user experience (UX) requires more than writing user stories. Also consider the user journeys and interactions, the visual design, and the nonfunctional properties of your product. This results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience.

Agile Development SMART Tasks

A task communicates the need to do some work. Each team member can define tasks to represent the work that they need to accomplish. For example, a developer can define development tasks to implement user stories. A tester can define test tasks to assign the job of writing and running test cases. A task can also be used to signal regressions or to suggest that exploratory testing should be performed. Also, a team member can define a task to represent generic work for the project.

You link tasks to a user story to track the progress of work that has occurred to complete that story. After you define a task, you can link it to the user story that it implements

During the Iteration Planning meeting, stories and sometimes defects are broken down into tasks. The tasks are all the work the team must complete to develop, test and accept the story as done.  Tasks typically range in size from 1 hour to 2 days, depending on the length of the iteration. Two-week iterations ideally have tasks of 8 hours or less, and four week iterations have tasks sized at 2 days or less. Tasks larger than these guidelines should be broken down further to allow the team to incrementally complete the work and show progress. Keep tasks small. Estimate all tasks in hours. Iteration tracking will be done at story level to keep the team focused on business value.

The entire team works together to come up with the tasks for all the stories identified for the iteration. The majority of the tasks are determined during the iteration planning meeting, but in some cases the team may discover tasks as the work starts. It is appropriate to add and/or remove tasks on stories during the iteration.

When a task involves an external group – perhaps you want to demo your system to some project stakeholders, or deploy a testable version into your QA/test environment – then you should consider including the task as a reminder to coordinate with those groups.

Tasks may include the traditional steps in a development lifecycle (although limited to the feature in question, not the entire product). For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc. Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.

At the end of the day , the individuals update the tasks hours remaining for the tasks they have taken responsibility . This will enable to determine the Burn down chart.

Tasks makes the micro work break down structure that the teams can use to facilitate coordinating, estimating, tracking status and and assigning individual responsibilities to help assure completion of the stories. and there by the iteration

There is an acronym for creating effective goals: “SMART” –

S – Specific
M – Measurable
A – Achievable
R – Relevant
T – Time-boxed
These are good characteristics for tasks as well.


A task needs to be specific enough that everyone can understand what’s involved in it. This helps keep other tasks from overlapping, and helps people understand whether the tasks add up to the full story.


The key measure is, “can we mark it as done?” The team needs to agree on what that means, but it should include “does what it is intended to,” “tests are included,” and “the code has been refactored.”


The task owner should expect to be able to achieve a task. XP teams have a rule that anybody can ask for help whenever they need it; this certainly includes ensuring that task owners are up to the job.


Every task should be relevant, contributing to the story at hand. Stories are broken into tasks for the benefit of developers, but a customer should still be able to expect that every task can be explained and justified.


A task should be time-boxed: limited to a specific duration. This doesn’t need to be a formal estimate in hours or days, but there should be an expectation so people know when they should seek help. If a task is harder than expected, the team needs to know it must split the task, change players, or do something to help the task (and story) get done.

As you discuss stories, write cards, and split stories, the INVEST acronym can help remind you of characteristics of good stories. When creating a task plan, applying the SMART acronym can improve your tasks.

Scrum and Sprints

The task board is the single most important information radiator that an agile team has. A task board illustrates the progress that an agile team is making in achieving their sprint goals. Usually the task board is located in an area that is central to the team

All of these task boards have a few simple things in common:

1) 4 basic columns (there can be more)

  1. Stories
  2. To Do
  3. In Process (In progress, WIP, etc.)
  4. Complete (Completed, Done, etc.)

2) A Row for each story

Simple task board


More complicated version that looks something like above.