Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

Previously we used duration for each story, but in our current sprint we are using story points (effort) keeping test team effort separate from the development team effort. Story points are based on complexity, effort, and doubt. These three points will differ for a developer/programmer than with someone creating manual tests or someone creating automated tests. How can all of these different factors be combined to created an overall story point estimate?

According to Scrum these should be combined (as it's a team effort), but how is this done? Is it just combining the developers' and testers' efforts, or do testers and developers have to estimate the combined effort? If the latter, are there guidelines for this to work effectively?

share|improve this question
1  
A Scrum team should be a cohesive team; having sub-groups defeats this goal. –  CodeGnome Feb 8 '13 at 19:29
add comment

4 Answers 4

TL; DR

Story points represent consensus within the team. The goal of estimating story points is not to provide the largest or smallest estimate, but to accurately reflect the effort required by the entire team to meet the "definition of done."

Lewis Carroll Does Scrum

Consider a story like:

As a practitioner of Extreme Dentistry,
I want to know how many teeth the average Jabberwock has
so that I can hire enough dental hygienists.

During a round of planning poker, the programmers on the team might estimate this story at only two points, since adding a tooth-count column to a database table is a minor change for them. However, the testers might estimate this story at 13 points, since getting close enough to count a Jabberwock's teeth to gather accurate fixture data is a dangerous (and potentially fatal) task.

Should the story be two points, or thirteen? That's up to the team. Maybe the whole story is really 13 points overall, or the team discusses it and realizes that the story really ought to be 21 points once they factor in the need for an emergency medical team to be kept on standby. Then again, perhaps the team decides to reduce uncertainty by switching in a five-point Vorpal Sword story as a prerequisite, which reduces the Jabberwock story to only eight points in the next sprint.

Getting Consensus

Sometimes getting consensus is hard. That's why planning poker uses time-boxing, so that consensus-building doesn't take infinite time. Remember, you can also call on the Product Owner to clarify stories, decompose stories, or swap out stories for something else on the Product Backlog. Some level of consensus should always be possible.

If a story is accepted into the sprint, at the end of the time box the team must record an estimate. This estimate may be:

  1. The average of the estimates.
  2. The mean of the estimates.
  3. The worst-case estimate.
  4. The best-case estimate (but please don't do that).

Failure to estimate properly will become obvious during the sprint, and will provide good grist for the mill during your next retrospective. Continuous process improvement is the name of the game, after all.

share|improve this answer
1  
I really like the 'TL;DR' approach at the top of your answers. +1! –  Tiago Cardoso Feb 11 '13 at 16:53
    
Love the example! –  Ben May 28 at 9:28
add comment

The team should come to a consensus on the combined effort

You want to work towards the ideal of a cross-functional team and the team owning all the stories rather than individuals. While that is a long term goal, you want to look for practical steps you can take to resolve these issues in the meantime.

To answer your question, the team should come to a consensus on the combined effort. As CodeGnome suggested, start planning poker sessions for estimation, if you are not already doing so. Let each team member understand the scope of work and come up with their own estimate, without being influenced by others. The discussion that follows should focus on the reasons for the lower or higher estimate. That will foster a better understanding of the development and testing work content across the team. We have also seen some misunderstandings get clarified. For example, the developers might point out that they will be messing with the base classes and that might warrant a wider range of regression tests than what the testers planned.

share|improve this answer
add comment

There are a few reasons for estimating:

  • To work out how much the team can commit to doing, each Sprint, in order to manage stakeholder expectations
  • To plan releases based on how much work the team can do
  • To see if there are any discrepancies in understanding of the work that needs doing.

With respect to the discrepancies, there are plenty of other ways to uncover this without estimating. I like to use Behavior-Driven Development's scenarios in conversation for this; if you can decide which scenarios are in and out of scope, and ask questions designed to find missing or unclear scenarios, you'll usually find out if there are misunderstandings or work that could be descoped for another story.

With respect to how much the team can do, and planning releases, you can think of the team as a pipeline. At any point, there will be one role whose time is constrained, and which represents the narrowest part of the pipe. By considering how fast that constrained role can work, you can see how fast the work can flow through the system.

It's usually the case that developers can help overworked testers, but testers can't always help developers as easily. For that reason, frequently developers are the constrained role, and if that's the case in your team then I would suggest worrying about the development effort rather than the test effort. Including complexity and doubt in the estimate is a great idea. If the constraint ever moves away from the developers, you can change the role that does the estimation.

It's still worth talking through the test effort as this may impact how much work will fall to the devs. Note that developers and testers have very different mindsets, even when their skills are similar, so while they can collaborate effectively it's not always the case that they can take on each other's roles with flexibility.

As a final note, story points are meant to be a lightweight way of planning and setting expectations. Teams that worry too much about accuracy tend to inflate stories so that points become worth less and less, and there are more of them, and also tend to spend more time on their process when they could actually be getting work done.

For this reason I prefer Kanban, which makes the constraints in flow very apparent and explicit, while providing more flexibility than Scrum's sprint cycle. Cumulative Flow Diagrams are also a great way of spotting constraints in either framework.

share|improve this answer
1  
@tiago-cardoso BDD in this context stands for Behavior-Driven Development, not Binary Decision Diagram. Changed the URL you added. Can you tell me more about why you thought the answer was about the other kind of BDD? I'd like to avoid that misunderstanding in future. –  Lunivore Feb 11 '13 at 22:12
    
Hello Lunivore, I wasn't aware of what BDD stand for, so I googled it and got the Binary Decision Diagram. Strangely enough, I have no idea how my googled didn't return the Behaviour-Driven Development... as all searches I do today are pointing me to Behavior Driven Development. Apologies. Either way, we've been discussing about how we can approach the usage of acronyms in PMSE, and your opinion is welcome! –  Tiago Cardoso Feb 13 '13 at 10:53
    
@tiago-cardoso Thanks for pointing me at that. I've expanded the acronym to avoid confusion as suggested in the usage question. Cheers! –  Lunivore Feb 13 '13 at 11:00
add comment

It's still worth talking through the test effort as this may impact how much work will fall to the devs. Note that developers and testers have very different mindsets, even when their skills are similar, so while they can collaborate effectively it's not always the case that they can take on each other's roles with flexibility.

As a final note, story points are meant to be a lightweight way of planning and setting expectations. Teams that worry too much about accuracy tend to inflate stories so that points become worth less and less, and there are more of them, and also tend to spend more time on their process when they could actually be getting work done.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.