0

Hypothetically speaking

  • There's one big project that requires involvement from different members - infrastructure, backend, frontend, security, etc.

  • The members are working a flavour of Scrum using Jira to keep track of the progress.

  • Story Points (SP) are introduced, following Fibonacci numbers and the estimates are done only by the member in charge of the User Story / Task / Sub-Task (let's call that member => task owner).

  • The Product Owners and Scrum Master expect the team members to deliver 5-8 SP per 2 week sprint. This can be a SP given to one or more User Stories / Tasks / Sub-Tasks.

  • Seven members deliver maximum 8 SP. One of the members delivers consistently 55 SP (for the third sprint now).

  • The Scrum Master wants to keep the burn down consistent. So, his solution is to change the 55 SP estimate to 8 SP.

  • The member who evaluated in 55 SP has strong opinions that justify the value of 55 SP (in light of the other existing estimates) and sees one of the following things -> he's being told to work less OR the work is being devalued.

How to proceed in this scenario?

I'm aware of this question - How should a team handle disagreements about story-point estimates in Scrum?

The difference is that the case I describe is more specific and the estimates are done only by one person - the one working on the task.

Improve this question
2
  • 1
    I don't want to be critical, so I thought I'd ask: do you want an answer that picks apart how non-Scrum some of the company's practices are, or are you just trying to reconcile the 10x variance in point estimation? I could answer either way, but it's hard to tell what kind of answer you really want here because of the level of detail.
    – Todd A. Jacobs ♦
    Mar 23, 2022 at 22:01
  • Thanks for making the time @ToddA.Jacobs. I'd say an answer that covers your thoughts on Story Points usage for that context would be great. For reference, that one developer is working in a project / service that the others will interact with but using technologies the others aren't necessarily using.
    – Tiago Martins Peres
    Mar 23, 2022 at 22:42

2 Answers 2

Reset to default
5

There are a lot of problems with what is going on here.

The first thing that stands out is what you describe as a team doesn't seem to be a team. A team is "a group of individuals (human or non-human) working together to achieve their goal". Although you have a group of individuals and you may have a shared goal, it seems like everyone is working on their own work as individuals. It's not a collaborative environment. A good Scrum Team is highly collaborative, creating plans and goals, executing on work to achieve those goals, and regularly adjusting their plans and actions.

Story points are also relative estimates. Originally, they were a representation of ideal time and a load factor to help a team decide how much work they can achieve in a Sprint. Today, they are often viewed as a measure of size, effort, or complexity. Although there may be a relationship between size and complexity, it's not a direct relationship. There can be a complex piece of work that comes together nicely and is done quickly. There can also be small amounts of work that require a lot of time and attention to detail to get right. If you're trying to equate points to time, I'd recommend estimating in ideal hours and figuring out how many ideal hours exist in your two-week Sprint. There would be no more arguing about if something is an 8 or a 55 if someone asserts that it would take them N hours and they are the ones doing the work.

Keeping the burndown consistent is not a good reason for doing anything. The burndown is a visual representation of progress. It should reflect reality. Since everyone is estimating their own work, everyone should be able to determine the relative size or complexity of their work against every other piece of work and, from time to time, adjust their relative sizing to match their changing understanding of the work and the context.

Assuming that you can't fix the underlying team issues, I'd focus on understanding why you are estimating and what you hope to achieve out of not only the estimates but visualizing the burndown.

Also, I would suggest not using terms like "flavour of Scrum". Either you are implementing Scrum as its defined in the Scrum Guide or you aren't. Although implementing only some aspects of what is described in the Scrum Guide may be fine for your team(s) in your context, it's not Scrum.

Improve this answer
1
  • I agree. The level of complexity of the project can be such that it's a case where each member can grow to become own teams within a bigger team... and from that perspective wouldn't make sense to compare SPs between them
    – Tiago Martins Peres
    Mar 22, 2022 at 0:34
2

To answer your question shortly:

When you have one of the team members delivering much more than the rest you need to slow down to speed up. Meaning investing time of the senior developer to train and mentor the ones that are lagging behind, so yes he won’t be delivering 55SP anymore in the short term, but in the long term you’ll have multiple engineers delivering more SPs.

Bonus: The reason why all engineers in the team should estimate the tickets and not only the person that will work on it is that they will need to explain themselves when big differences in estimation happens. The conversation alone is already helping to mentor the team on complexity

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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