Size and Estimate for Your Team

Print this topicEmail this topic

Sizing and estimates includes the following topics:

What is an estimate?

Before you schedule work, you need to know how large it is. Can you fit two user stories into the next iteration? Four? More? The practice of estimation is necessary to answer these questions. Rally allows for sizing and estimation for use prior to and during iteration planning.

Begin by watching this brief video that explains the differences between sizing and estimation:

Sizing and Estimating
Sizing and Estimating (5 min)

User stories

An estimate is a recorded measurement of the effort necessary to complete a user story. When you estimate stories, you estimate as a team. Collaborative estimation ensures that every member of the team is committed to the work being planned. Cross-functional dependencies, potential issues, and strengths that accelerate progress may be uncovered through team estimation.

Rally uses the Plan Estimate field to record the estimate of each user story. You can use your Backlog page to display the Plan Estimate column, and easily edit the value by double-clicking the field.

Plan Estimate field

The default unit type used by the Plan Estimate field is points. Think of this as a relative, abstract value that represents overall team effort. You can change the unit type to represent other numerical values such as weeks or months, but we recommend a simple Fibonacci-like number sequence.

Here is a sample point value set: 2, 3, 5, 8, 13, 20, 40, or 100 points.

Point estimates are also entered into the Planned Velocity field of iterations, prior to iteration planning. This value represents the total number of story points (or other value) the team believes they can complete in an iteration. This total is also known as a team's resources. You can calculate velocity by averaging the total number of accepted points from the past several iterations.

Teams new to Agile and may see their velocity fluctuate at first (in one iteration you may complete 13 story points, and in another 20), but as the team learns to work together, the number will stabilize.

Resources field

Note: If your team provides a story estimate that is larger than the total velocity for an upcoming iteration, you are in trouble! The team can only commit to work that can be completed in a single iteration. To estimate large stories or initiatives, break the story down into smaller child stories. As a story moves up the backlog, continue breaking the contents down into the smallest size possible that delivers value.

Tasks

After a user story is scheduled, the actions or steps necessary to provide the story’s value are identified. These actions are recorded in Rally by creating tasks. Tasks also contain fields to estimate and track effort, but the measurement values are different.

Story and tasks

Generally, tasks are volunteered for and owned by individuals. Owners provide an initial estimate of hour many hours he or she believes it will take to complete a task. Unlike story points, task estimates are not abstract. Story points provide upper-level visibility into "Can we finish this work before our iteration commitment ends?", while task estimates provide daily visibility into "Will my teammate finish coding this section of the user story before the end of the day?".

The default unit type for tasks is hours. The type can also be changed, but we recommend creating tasks that take between 1-6 hours to complete. This keeps work within the scope of a single day, so that the team can alert each other of progress and problems in daily standup meetings.

Rally lets you record the initial hourly estimate of a task, and the time remaining until completion. The Task Estimate field is used during the iteration planning when the task owner performs the initial estimate, and that value is automatically copied into the To Do field. At the end of the day or prior to status meetings, the owner can update the To Do field to reflect how many of the initial hours remain.

Task estimate fields

Important: Avoid the temptation to correlate the total number of task hours with story points. Do not have discussions like this: "Well, this story appears it will involve 20 hours of work, so we'll estimate this story as 10 points. Our team has learned that 2 hours of work is equal to 1 story point." This can greatly hinder estimation. As your team matures, you may start noticing that work of a certain point size averages a number of task hours. Such an acknowledgment is useful, but only to verify the accuracy of estimates after an iteration has ended.

What about defects?

Should existing defects in your system be estimated? When possible, your team should use the same point system to estimate defect fix work as user stories. The value in this practice is that defects subtract from total velocity of the iteration. If a team has an average velocity of 20 points per iteration, and a 2 point defect is scheduled, the team knows not to commit to two additional 10 point stories, as they likely will not be able to finish.

Defects in Rally also use the Plan Estimate field to record points.

Sizing and estimates

There's an old saying in Agile — We often underestimate the size of work, and overestimate our ability and time to complete it. Correctly estimating the size and scope of upcoming work is essential to planning and executing Agile projects in Rally. When a team knows how to estimate, they can accurately predict how long a task will take to complete that day, determine how many user stories fit into an average iteration, and how a change, defect, or other issue may affect a long-term goal.

The following estimate fields are used in Rally:

  • Release units: The estimated amount of resource units available to a release.
  • Iteration units: The estimated amount of resource units available to an iteration.
  • Plan Estimate: This field records the amount of effort estimated by a team to complete a user story or defect.
  • Planned Velocity: The amount of Plan Estimate points a team estimates they can complete in a given iteration. This total is also known as available resources.
  • Task Estimate: This field records the amount of effort estimated by an individual to complete a task.
  • To Do: The amount of actual time remaining to complete a task.

Most estimate units roll up into cumulative totals and can be viewed on the Iteration Status or Release Status pages.

How do we estimate?

Your team can use several different techniques to estimate work. Whichever method you prefer, make sure the actions are collaborative. Remember, team members are responsible for providing estimates, not the product owner.

Planning poker

Planning poker is an easy, fun way to estimate and get the discussion flowing:

  1. Create or purchase a set of planning cards for each team member. Have a card for each value in your point system: 2, 3, 5, 8, 13, 20, 40, 100 (or similar)
  2. Bring up the proposed story on a monitor or board. Explain what value the story will provide, and the initial requirements.
  3. Give team members a minute or two to select a card, face down.
  4. On the count of three, all team members raise their hand, displaying the card.
  5. Find the lowest and highest card values.
  6. Have the lowest and highest card holders each take two minutes to explain why they think a story is a certain size.
  7. Provide a few moments for others to weigh in, should the discussion uncover any problems or requirements.
  8. Re-vote until a consensus value is reached.
  9. Enter the estimate value in Rally.

Planning Poker

Example and comparison estimates

If your Agile team is new, but team members are familiar with past work, you can use examples and comparisons to estimate. Rally development teams have used this strategy combined with planning poker to generate story estimates.

Create a chart of well-known stories of various sizes, and have the team agree on corresponding point values. For example:

Chart on a whiteboard

Post a copy of this chart in the team working area, or wherever you host backlog grooming and planning meetings. When using recognizable comparisons, the team can have discussions like this: "I remember how long it took us to create the recycle bin, and this seems about the same amount of effort, so this story should be estimated at 8 points."

When do we estimate?

As with planning, estimation is a continuous process. Estimation and planning meetings take place repeatedly over the course of an iteration cycle to ensure a team is prepared. Teams look two to three cycles ahead, in order to anticipate and respond to potential changes.

Prior to iteration planning, the top portion of the backlog should be both prioritized and estimated. It is the responsibility of the product owner to rank the user stories and defects by importance, so the team can provide estimates for each item.

Items that may not be done in the near-term can be placed on the backlog, but do not need detailed estimates. Estimates for items further down the backlog can get stale, and will need to be re-done prior to planning. It is common to create a user story to act as a placeholder and description for a long-term feature or theme. As time passes and the story moves up the backlog, it can be broken down into smaller chunks to document each aspect or function of the feature.

Backlog grooming

Who estimates work?

Developers, testers, tech writers, and other contributors estimate work collectively in team meetings. Product owners should not provide estimates when adding user stories to the backlog. The product owner is responsible for communicating what needs to be done, and the priority of each item. The team is responsible for estimating the size of the work, communicating expectations to the product owner, and then carrying out the plan. With this practice, contributors are truly empowered to take charge of the work.

Why do we estimate as a team?

Estimation as a team also serves as a bonding tool, because it involves discussion. Through conversations, team members learn about each others responsibilities and abilities. In future iterations, a developer may be able to anticipate a technical writer's load, or vice-versa. Team members with similar skill sets also learn more about the product through these discussions.

For example, one developer thinks a story is 8 points, while another thinks it is only 3. When asked why there is a difference, the more experienced developer reveals a caveat with the portion of the code that is being edited. Now the junior team member is familiar with this exception, and can utilize such knowledge in future estimation sessions.

During the latter part of the iteration planning meeting, individuals may provide values for hourly task estimates, but the team is still present to collaborate. Again, this serves to educate other team members of the size and scope of work done by individuals in various roles, and holds task owners accountable for their estimates.

What if an estimate is large?

During the course of backlog grooming and planning, initial estimates may reveal that a user story or defect is too large to fit into a single iteration. When that happens, the story must be broken down. It's best to perform this breakdown as a large user story moves closer to the top of the backlog. As business needs and strategy change, you may find yourself delaying or canceling a user story that is several months away. Don't spend unnecessary time adding meticulous detail to work that may not be scheduled.

How work breaks down over time

What does the estimation cycle of a new story look like?

Click the image below to launch an interactive timeline that follows a new story from the bottom of the backlog to iteration planning. You will be able to see who performs various estimation activities, and what meetings are used to discuss the story.

Story 
Estimation Timeline

Feedback

Please send us your feedback regarding our help site. For feedback regarding the Rally product, click here to open a support case or click here to submit a new feature request
English
By submitting this form, you accept the Mollom privacy policy.
© 2014 Rally Software Development Corp | Legal