Story Points given by task owner leads to disagreement



  • 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 - https://pm.stackexchange.com/q/8410/27189

    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.



  • 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. https://en.wikipedia.org/wiki/Team . 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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2