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.

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 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. Mar 23 at 22:42

1 Answer 1

4

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

The first thing that stands out is what 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 determine how much work they can achieve in a Sprint. Today, they are viewed as a measure of size or complexity. Although there may be a relationship between size and complexity, it's not a direct relationship. There can be a very complex piece of work that comes together nicely and is done quickly. There can also be very 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 each individual is estimating their own work, each individual 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.

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 Mar 22 at 0:34

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.