5

My team consists of 2 backend devs, 1 front end dev and designer. Lets pretend we have next user story:

As a user I want to sign-in/sign-out to use the system

Designer says that it is equal to 2 story points. Back end devs believe, that this is a 1 point story, while front end dev thinks, that it equals to 3 points (due to animations,transitions etc.) What amount of story points should be the outcome of this user story?

Should I sum up the overall number of points for 1 user story?

Should I split the user story to 3 different stories? (backend, frontend, design)

Should I just lean to the maximum story point value?

17

When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members).
The advantage of using story-points here is that the values are relative to previously estimated work and most people are able to estimate if something is less/more/a lot more work than a reference story, even if they do not have the competences to actually perform the work itself. This way, the front-end dev can take the work of the other disciplines into account when making his estimate for the complete effort to finish a story.

Once you have everyone estimating the complete effort, it is still possible that different people come up with different estimates. The usual reasons for this are

  • The acceptance criteria for the story are not specific enough, causing some developers to see the story as broader than the others do,
  • Some developers see risks or additional effort that some others overlooked
  • Sometimes work you are not familiar with looks deceptively simple or complex, and that gets taken into account in the estimate.

If there are significant differences in the estimates, a discussion should be held among the team to find out where those differences came from and if everybody is on the same page.
With your example, chances are that the back-end dev overlooked the amount of effort that is needed to get all the right animations (or thought that it would be easy).

After everyone has had an opportunity to say what they considered in coming to their estimate, you can do a new round of estimations for that story. Most likely, the estimates will be much closer together.

If there are just small differences between the estimates, then you can choose to just pick one of the values (for example, the average value or the value that most people are on).

  • 1
    to add to what Bart said, you could ask the team to compare the story with a previously done story to get the estimates in relative terms. – Mincy George Feb 15 '16 at 15:47
  • But how would a front end dev know how many points the task will take from a designer, tester or back end dev perspective? – Ruslan Doronichev Jun 14 '16 at 11:24
  • 1
    @RuslanDoronichev: See my edit – Bart van Ingen Schenau Jun 14 '16 at 11:37
1

During the planning poker sessions average out (rounded up) story point estimates which are close to each other. In your example this would be come 2 story points.

Lets say you use the Fibonacci scale:

0 1/2 1 2 3 5 8 13 20 40 100

When the estimations are more then 3 steps apart, say 1 and 5, then discuss and re-vote. When the estimations are less then 3 steps away, say 2,3,5, average them rounded up.

The reason to average is because you don't want to spend to much discussion on things the team relatively agrees on. As the story points are used as a forecast its not to important they are exact. The fault margin will compensate on average on all estimations.

I got the averaging from the book Scrum: The Art of Doing Twice the Work in Half the Time, where Jeff Sutherland suggested this. I think it makes total sence.

1

Short Answers

Should I sum up the overall number of points for 1 user story?

No. Summing developer guesses will yield efforts that are much larger simply because more developer are guessing.

Should I split the user story to 3 different stories? (backend, frontend, design)

Probably not. Rather, ensure that each piece of work represents a valuable increment of the software with clearly expressed business value, if at all possible.

Should I just lean to the maximum story point value?

Yes and no :). When there is a wide gap between developer guesses, encourage the devs to figure out why their guesses have diverge. With narrower gaps, tend toward the higher number.

Sum Up

Ultimately, commit to consistency, rigorous inspection and adaptation in whatever techniques you adopt. This ensures that good practices will emerge and bad ones will fall by the wayside.

0

Just came across this (rather old) post.

I'm managing a team of dedicated frontenders and backenders. It'll be a cold day in Hell, when they start doing each other's work :-)

My concern with the community score, is that it gives a false velocity for the team, in the case of having dedicated Front- and Backend developers respectively.

EXAMPLE: Say a story ends up at 20 story points, after a healthy discussion in Refinement. Of these 20 points, it was clearly the backend developers stressing the complexity of building their part, whereas the frontenders needed only implement a new form. So the backenders account for 80% of the story points (so to speak, they are the ones who raised the score). Now, let's say the team has 4 backenders and 2 frontenders. And they make the above story in the sprint. All is well, and velocity could be said to be 20 story points per sprint.

Next refinement, tables are turned, frontend is a nightmare, backend a breeze, but it still adds up to 20 story points. Given that frontenders now have to do 80% of a 20-point story, with only 2 frontenders to do it, how does that affect velocity?

For the sake of predictability and getting a trustworthy velocity, I think the community score has some major flaws. Unfortunately, I have yet to find the fix for them :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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