Q: What is a point?
A: A point is a relative, abstract value to represent size. We know the difference between tiny and huge. Story
are a representation of this concept. You and your team determines what means what. Some teams may say 1 = tiny and 2 = huge, or 10 = tiny and 1,000,000 = huge. We recommend using a Fibonacci sequence to represent points.
Q: Why do you suggest estimating spikes using points? Spikes do not bring business value.
A: Because it is still work that the team has completed. If you have a 2-point spike, and the team averages 20 points of
, a chart may show 18 points of completed work. That negatively affects velocity, which is incorrect. The team did gain value by learning more about the proposed
Q: Is it okay to split stories during estimation with the team?
A: The moment the team determines that a story is larger than an entire iteration work of velocity, the story should be broken down. Break them down as small as possible.
Q: What is best practice for
when the team members are globally dispersed? Video meetings?
A: You can use video, instant messenger, or phone conferences to perform planning poker or other estimation techniques.
Q: I find people try to correlate the size-based estimation into days and hours and they do that by using the tasks feature; however, this tends to underestimate. How do you get the team not to correlate tasks to size-based estimation?
A: Focus on making story points abstract. Correlate the size of new work to similar work the team completed in the past. We know this is a common issue. Emphasize that correlation is useful, but only after an iteration is complete, to verify and adjust estimates, instead of upfront.
Q: Is a scrum master generally a full-time position? It seems like a potentially full-time job during planning and retrospective, but not for the full 2–4 weeks of an iteration when programmers are programming. Beyond daily Scrum meetings, what does a scrum master do?
A: Generally, yes, it is considered a full-time duty. Scrum masters help to unblock team members from issues in their way, represent the needs of the team to the business, and facilitate meetings. Meetings include the
, iteration planning,
or long-term planning,
and estimation, and retrospectives. If you have multiple teams, a scrum master can serve on more than one team.
Q: Is an example of a self-correcting story where we believe some functionality is coming from a third party provider, but find out later it is not?
A: Here is a great explanation of a self-correcting from an online article: Velocity and story points are entirely based on the environment and members of the team. A new addition to the team, for example, might change the definition of a story point, and will have a direct effect on the team’s velocity. A good aspect of velocity and story points is that they are self-correcting measures. Since the team’s workload is derived from them, it will also adjust accordingly to any change in the team or environment. Wrong estimates also tend to average out—while we underestimate some stories, we also overestimate others.
Q: Why is it okay to convert points into cost but not points into hours?
A: Hours is a much more granular estimate, and should not be relied on to provide cost. With points, you know generally if you are going to meet your iteration commitments. Task hours represent the daily commitments, and can be used at the end of the iteration to see if your point estimates are accurate.
Q: How can you estimate
duration when you have the stories and their relative size, but the delivery team is not co-located?
A: If the delivery team is co-located, you can still perform group estimation activities so that you can compare the proposed work against the team's velocity. Using phone, video, conferencing software, CA Agile Central, and instant messenger, you can make your
room global, allowing for planning poker or other methods.
Q: Does size relate to the number of resources working on a story?
A: It relates to the team as a whole and their belief in delivery. That doesn't mean every team member works on every story in an iteration, but during estimation and planning meetings, discussions can take place that uncover skills and needs of individuals.
Q: I get resistance about items that get started within a
but not finished. The team wants to put some of the points into the original sprint, and then move the remaining points to the next sprint. I tell them that points do not accrue until the work is done, but they are concerned that it affects their velocity.
A: It should affect their velocity so that they may learn from the slip. At the end of the iteration, the team is able to view a chart that shows that they did not meet their goal. The team can then retrospect on why the issue happened, and strategize on ways to prevent issues in the future. Whether it is a technical blockage, a miss on estimation, or other factors, it is important to have this documented.
Q: Do you suggest providing estimates in days once we separated them in small, medium, and large? How many days do you suggest before a feature needs to be broken down?
A: Estimates should always be an abstract and relative value. If you give into the temptation of correlating a certain number of
story points to actual days or hours, you
the tendency to underestimate.
Q: Keeping stories fresh means often that we stay away from implementation details. However, the development team wants details in order to better estimate. How does the PO stay away from giving too much detail on how but still let the team do estimates?
A: One method for handling this situation is to focus on the what. Allow the team to ask questions about the value a
provides, so they can determine what makes up the how. For example, if you ask a development team to build a credit
system, they should have a discussion about what currencies you want them to support, which will help them estimate size.
Q: What is the proposed best practice for developing velocity and
charts for different teams on the same project?
A: One suggestion is to use tags in CA Agile Central, so that you may take advantage of the Story Burndown charts. This allows you to track all work across multiple projects over the course of iterations and releases.
Q: How can one tell when an iteration can finish if there is no estimate in hours?
A: Over time, your team will learn what their velocity is. Velocity is the average number of story points that can be completed in an iteration. With this value known (approximately), the team can plan within this figure, and know that they will most likely be able to finish.
Q: What factors does the team need to take into account when assigning story points to a story?
A: Size, complexity, and risk.
Q: What is the minimal project length that makes sense to apply the Agile methodology? If our software development projects tend to only last 4–6 weeks, don't you lose some of the Agile principles?
A: The great thing about Agile is that it can be adaptive. While two-week iterations are a familiar standard, you can have one week iterations (or even shorter) to accommodate the project. As long as you are prioritizing the work of the project, estimating the size, committing to the requirements, and retrospecting to improve on the next project, you are being Agile.
Q: What about a moving
—the size always changes because the
never knows what they want at the beginning of the marathon.
A: The overall size, or set of features that a customer asks for may change, but this shouldn't affect individual user stories once they have been scheduled. Part of this problem may be solved through customer education. Set the expectation that you work in 2–4 week sprints, and that once a sprint has begun, its course is set. If the customer does not like the results of a specific iteration, they must be present (or through the product
) to help refine the
to their needs for upcoming work. It's a tough balance, CA Agile Central has thousands of feature requests but can only get to so many. One strategy we use is to host a quarterly customer council. Through this, we have released most of the top most requested items, while being able to continue work on important internal stories.
Q: In estimating, when do you switch from relative sizing (S, M, L) to story points?
A: Use a number system that works best for your team, but ensure it remains relative. We really like Fibonacci-style sets: 2, 3, 5, 8, 20, 40, 100. The key is to not fall into the trap of two points = two hours, days, and so on.
Q: How do you estimate accurately when there are several dependencies affecting the tasks of a user story?
A: Those dependencies should be uncovered and discussed by the team during meetings. Such dependencies increase the complexity of work, which can increase the initial story estimate.
Q: CA Agile Central has tasks which asks for hours or days type of estimate. I find it difficult to get the team
size based estimation because of this.
A: User stories are estimated by the team with the relative, abstract value of points. After a team commits to those stories, tasks may be used to help individuals provide short-term estimates as to their ability to complete steps to bring that user story closer to completion. This can be done in hours, to ensure a team member has enough
during the week to handle the work load. Check out the Sizing and Estimating video for an explanation of the difference between the two values.
Q: Why call it velocity, instead of speed? How fast teams can progress?
A: Velocity is a term used by many Agile organizations, so if you're joining us from another learning provider, we want to make sure we use the same verbiage. Learn more about velocity here.
Q: If a story with 10 points is only partially finished in an iteration, how do you deal with that at the end of the iteration?
A: When you are unable to complete a story in an iteration, it is all-or-nothing credit. Since the story cannot be accepted, that iteration's data will show a 10 point learning opportunity (miss). That serves as a reminder to discuss why the story was not finished in the next retrospective meeting. Whether it was an incorrect estimation, technical issue, or other problem, actions can be taken to prevent the same miss in the next iteration. For the next iteration, you will re-schedule the same 10 point story. However, the team can re-estimate the remaining work, to ensure they have enough new story work to complete as well.
Q: Do you take into consideration who will do the task (a large development for a junior developer may just be a small one for a senior developer)?
A: When you estimate the size of a user story, you're estimating as a team, not an individual. When a story is planned, you create tasks and team members volunteer for them, providing personal hourly estimates. Individual estimates are only for an individual's part of this story, but the entire team has committed to the story.
Q: Do we still differentiate developers and QA members in scrum methodology?
A: With scrum, your team should be
. That means it contains members with all the skills necessary to deliver a user story. We talk a bit about vertical slicing, which is the concept of writing user stories such that multiple team members can work in parallel, instead of QA stories and Development stories.
Q: Is 20 points considered twice as big as the one with 10 points?
A: Yes. Numbers are useful because like points, they remain abstract. They do not tie back to hours in a day, or days in a week. They are the same as words like large, big, or huge. In fact, you can set up the Estimation Board app in CA Agile Central to assign a point number based on these terms and rely on the terms to break out of correlations to actual time.
Q: Spikes are estimated in points, the same as user stories?
A: Yes. It is generally a smaller number, unless the research requires a large effort.
Q: What does size include? Sum of expected efforts, complexity, risk? What else?
A: Those are the main three aspects of what size includes. Watch the Story Points video to see an Agile coach explain what factors into this size.
Q: Is there any
on the maximum hours that can be assigned to a task within a story?
A: Yes. We recommend one ideal developer day, which is about 6 hours. If a task takes more than a day, then the value of providing status at the Daily Standup meeting is lost.