5

Let's suppose we have a common Scrum team comprised of a frontend developer (one or two), backend developer (one or two), tester, designer. Let's further suppose that we need to estimate a User Story using Planning Poker. How do we do this?

The frontend developer can't estimate the backend part of the work, so they only say "As a fronend developer I forecast that implementing the frontend part of the work will require 2 Story Points." The backend developer more often than not has nothing to say about this estimate because of the lack of expertise in frontend technologies. The other members of the team (tester, designer) have even less expertise in the frontend development so they also don't participate in estimating. Thus the estimation is effectively made by a concrete technician and not by the development team.

Effectively each member only estimates their part of the work.

Planning Poker looks to be more suited for non cross-functional teams, for example, the backend development team (comprised of Java developers) or for the frontend development team (comprised of frontend developers).

What should common teams comprised of common (not having variety of experience) developers do? Can't they be a Scrum team? Frontend developers in my team can't foresee risks related to the highload backend tasks developed by our backend developers. And our backend developers have little knowledge about complexity of modern frontend frameworks (Angular, React, etc).

They can't estimate what they never do - it is clear. If Scrum Master insists on learning to do "team-made" estimates the team just makes them up.

Daniel
  • 2,729
  • 13
  • 36
  • 1
    "Effectively each member only estimates their part of the work." Are these parts independent? Can you deliver a Story with only part of it? If the answer is yes, then no problem. If the answer is no, then you're estimating something (that's not a Story) using Story points. – Tiago Cardoso Nov 22 '20 at 14:12
  • @TiagoCardoso But the estimation need to be made by the whole team to exclude possibility of a member giving any estimate he wants. – Daniel Nov 22 '20 at 15:02
  • "exclude the possibility of a member giving any estimate he wants". Why excluding this possibility? You want the team to be accountable for what they deliver, and you can only achieve that empowering them. Agility requires maturity, and a true agile developer will take estimation with due seriousness. – Tiago Cardoso Nov 23 '20 at 00:05
  • I totally get the problem. I face it too. I'm still getting my head around my own answer. I'm not entirely sure about what has to be done. I know what has not to be done, and that's restrain the team. – Tiago Cardoso Nov 23 '20 at 00:07

3 Answers3

5

The power of planning poker lays in its consensus-based collaborative approach. You don't simply estimate the size of something, you have a discussion during which each member contributes to the understanding of what needs to be built. As a whole. And then together as a team also decide what size that whole is.

When you have a team of full stack developers, then things are simple. Anyone can more or less do anyone else's job, so they can estimate the story as a whole in one shot. Case closed.

When you have specialists, like front-end and back-end developers, with some team member's expertise not covering one part or another of what needs to be built, things are a bit more difficult but that doesn't mean they can't figure out the size of something as a whole. It's about self-organization. The team just needs to find a way to add their pieces together to form the entire whole.

Maybe back-end developers estimate their part, front-end developers their part, testers their part, then discuss how their pieces fit together and see what the total is. That might mean adding the story points together, or figuring out there is some extra integration needed, or something else needs to be tested, so they give it more story points than the sum of their individual contributions, etc. The team needs to figure it out.

I'll repeat what I said in the beginning: the power of planning poker lays in its consensus-based collaborative approach. Even if, for example, the front-end developer doesn't provide an estimate to the work the back-end developer does, they still need to collaborate, they still need to ask questions, they still need to look at the whole thing not just their part. When you take a user story and split it in tasks like "database queries", "back-end work", "front-end work", "testing" which everyone then estimates separately based on their special skills, what happens is that you create walls within the user story over which people can throw work to each other: I've done my part, now it's your turn. That's not really how collaboration should happen in a Scrum team.

So if people can figure out how to work together and make their parts fit together as a one functioning user story that can be deployed to production, they can also figure out a way to use planning poker to get the size of something from the sizes of their own effort and perspective. They will just need some time and they might experiment with a few options until they find something that works well.

Bogdan
  • 15,216
  • 27
  • 48
  • They can't estimate what they never do - it is clear. If Scrum Master insists on learning to do such team-made estimates the team just makes them up. – Daniel Nov 22 '20 at 15:18
  • 4
    @Daniel "They can't estimate what they never do" that's not true. We are talking about relative estimation. I can estimate the relative complexity of building different sized houses even though I'm not a builder and know nothing about construction. If your team doubts this then why not set up a workshop with an agile coach so that they can try it outside the pressure of their actual workload. – nvogel Nov 22 '20 at 15:48
3

"As a front-end developer this looks quite simple, maybe just a 2 pointer."

"Hmmm, the back-end is going to be tricky, more like 5 points."

"Testing this won't be easy either."

"OK, shall we go for 5 points then? Or maybe even 8?"

"8 seems excessive given the front-end work is pretty simple. 5 seems good."

Barnaby Golden
  • 19,475
  • 3
  • 17
  • 50
  • This is not Planning Poker - the main goal is not achieved. – Daniel Nov 23 '20 at 18:14
  • 2
    I think Barnaby describes the poker process quite well. The goals of poker are to achieve consensus, allow everyone to contribute and allow people to learn from each other. – nvogel Nov 23 '20 at 21:02
1

Most people on a team have experience of more than one technology and have worked before on multi-disciplinary teams where they can see how things fit together. I know more Java and Python than C++ but I can have a sensible go at estimating the size and complexity of a problem to be solved in C++. I can contribute to a discussion on a C++ solution if only by asking some "dumb" questions when a more experienced C++ developer tells me it is more difficult than I think.

Estimation is an ongoing process, not an event, and everyone on the team learns from that process each time the team estimates together. Relative estimation (points) usually focuses on size, complexity and risk of the problem to be solved, not units of time to solve it. Everyone who has worked in software development quickly learns what size, complexity and risk means.

It's also relevant that "cross-functional team" does not just mean a team composed of several specialists. It normally means a team of people with a variety of experience in different technologies and tasks and willing to get involved in areas outside their main expertise. Generalising specialists is the term often used.

It's wrong to assume the team members can only estimate the work they actually do. The power of relative estimation is that it allows people to estimate things without detailed knowledge of every task. I can estimate the relative complexity of building different sized houses even though I'm not a builder and know nothing about construction. If your team doubts this then why not set up a workshop with an agile coach so that they can try it outside the pressure of their actual workload.

nvogel
  • 6,295
  • 1
  • 9
  • 28
  • But what should common teams comprised of common (not having variety of experience) developers do? Can't they be a Scrum team? Frontend developers in my team can't foresee risks related to the highload backend tasks developed by our backend developers. And our backend developers have little knowledge about complexity of modern frontend frameworks (Angular, React, etc). – Daniel Nov 22 '20 at 11:31
  • They should discuss the story as a group. If the story is ready to do and sufficiently small then it shouldn't be very difficult to have a discussion about it and come to a consensus. If this is sprint 1 then estimation will be difficult and very approximate. The whole team will improve their understanding and be able to give better estimates in subsequent sprints. – nvogel Nov 22 '20 at 11:51
  • This is what we do. But the discussion turns into each type of developer giving an estimate for his part of the whole work. There is no team's estimate and we never calculate the team's velocity. – Daniel Nov 22 '20 at 12:56
  • 2
    Then they aren't actually playing poker and more importantly they are missing the opportunity to learn about the work being done by others. No one should be estimating "work". Instead the Scrum Master should encourage the team to arrive at a single points estimate for the size of the whole story, Estimates may be very inaccurate to start with but they will improve the more the team does it. Once they start sizing whole stories there is less incentive for individual members to game the estimate by upping the number for their bit alone. – nvogel Nov 22 '20 at 13:10
  • How does Scrum Master make a designer understand complications of the highload backend server or a tester foresee risks related to Angular programming? – Daniel Nov 22 '20 at 14:56
  • 1
    A Scrum Master shouldn't make those things happen. That should be part of the individual team members as they learn more about the overall team. A front end developer may not know about complications of a highload backend server, but planning as a team would provide visibility to those complications when the backend dev brings it up. Each team member would ideally become more knowledgeable through planning stories as a whole because they would see the entire story instead of just their specialized part. – jlowe Dec 02 '20 at 15:03