Convergence of Story Points

The convergence of your estimates doesn't seem that strange to me. The team has been working together for a while, so they have a good understanding of their capabilities and are in a better position to consider estimates from the "average member of the team" doing the work rather than their skills. They also have an increased understanding of the product and the domain. I'd even suspect that their ability to perform refinement has significantly improved as well, meaning that they can deliver smaller work.

As long as the team is capable of looking at the work and coming up with reasonable Sprint Goals and selecting Product Backlog Items that are likely to be complete, I wouldn't be too concerned. However, if the team were failing to meet Sprint Goals or could not select an appropriate amount of Product Backlog Items, I'd want to dig deeper to understand why.

Personally, this may be an opportunity to consider moving away from estimates. In the context of the Scrum Guide, the estimate of a Product Backlog Item is only to help guide the team in choosing an appropriate amount of Product Backlog Items for a Sprint. A quantitative estimate isn't necessary to do that. It could be sufficient to simply have a well-refined story that the team considers suitable for inclusion in a Sprint. As long as the team can craft a reasonable Sprint Goal and then look at a Product Backlog Item and determine that it can likely fit into the Sprint given the other Product Backlog Items, the purpose of estimation has been achieved.

 

How should we interpret convergence of story points?

Our scrum team has been working together for about 1 year. We noticed that the majority of tasks in the sprint backlog had same score. But, when the team started working together, the story point distribution was wider.

Are you talking about tasks or stories, and are the estimates really converging, or diverging as you subsequently suggest?

You refer to the Sprint Backlog. Is the timescale over which you observe any change therefore one Sprint?

Are you talking about tasks or stories, and are the estimates really converging, or diverging as you subsequently suggest?

I'm talking about tasks and really converged estimates. To put it more clearly, most of the tasks in sprint backlog have 8 story points. We use planning poker method and fibonacci numbers. 

You refer to the Sprint Backlog. Is the timescale over which you observe any change therefore one Sprint?

I can say that this observation based on 7-8 sprints (2-week-sprint). The development team was hesitant to take action on this situation at the retrospective meeting.

Hi Gizem, I've encountered the similar situation in my project. What I observed at the end is that the team didn't break the story small enough (usually they describe a whole function with a single user story), and sometimes IT team cannot make an accurate estimation of their effort until starting development, especially when it comes to working about integration/ developing some new components, which usually requires some extra time for doing POC.

Hi Gizem, I've encountered the similar situation in my project. What I observed at the end is that the team didn't break the story small enough (usually they describe a whole function with a single user story), and sometimes IT team cannot make an accurate estimation of their effort until starting development, especially when it comes to working about integration/ developing some new components, which usually requires some extra time for doing POC.

Thanks for the answer. I wonder your solution to this situation or have you developed a solution?

This is common problem to the Development Team when you are not fully embracing the Agile Mindset, I encountered this on my previous projects, however we over come it. As your team matures the critical thinking and decision making will evolve too. Adding Story Points only applies during your Product Refinements and Sprint Plannings to have better understanding on the PB. Ensure as well to have a deep connection to your Team, understand the weakness and strengths.

What we did in our Scrum Team is we gauge it based on what knowledge our Dev Team have. Ask questions with the help of your Subject Matter Expert (SME), App Arch or Dev Arch. Ensure to work as well with our Product Owner and have negotiations based on the capability of the Development Team.

Is the team experiencing this as a problematic situation or is it something you just happened to observe? Is the flow of PBI's steady and consistent or is there a fluctuation in how many of these 8 point tasks get done per sprint? Is the sprint goal achieved regularly or is there often work left on the sprint backlog at the end of the sprint?

If the flow is reasonably consistent, then your team has found a way to slice work to a consistent size. That's quite nice, as your team would be rather predictable. It might be a good idea to see if the work can be sliced a bit smaller, as smaller batches lead to higher throughput of value. The Scrum with Kanban learning material (or even better: the training) offers some interesting insights about how batch size influences flow.

I'm talking about tasks and really converged estimates. To put it more clearly, most of the tasks in sprint backlog have 8 story points.

Confusion alert. For me, in my subconscious, story points belong to stories which are written for product backlog items. This also means story points as estimates do not belong to tasks. Or is just my set theory knowledge fading?

But to answer the question, planning poker can easily lead to this. It was designed to avoid the anchoring bias and to make those people's voice heard who would otherwise not participate actively. The only glitch is that introverts are heavily overrepresented among development team members and they are not really happy to be the outliers who are requested to explain why they guessed differently. It seems in your team 8 is a safe bet. It will never differ too much from the median value, and if it does, the perpetrator can immediately close the inconvenient 'interrogation' with claiming to be slightly pessimistic or optimistic, move on.

It's an interesting situation. It sounds like your throughput is relatively stable and that the DT know what '8 pts' means to them - which is great! Estimates are great at helping the team know what they can forecast in a Sprint; it helps them to offer input into making the Sprint Goal realistic and achievable. However, if 'everything is an 8', my opinion would be that this isn't hugely transparent. 

The reason I say this is because estimates also help the PO order the Product Backlog (however they choose, but commonly by value). If everything is the same size, does this impact the PO's ability to order effectively? I think it might. It all depends on how your Scrum Team work. At the end of the day, the process is theirs to own and adapt (within the boundaries). You could try experimenting with different sizing techniques and review how they worked in the Sprint Retrospective?

I have 2 things in my mind:

1. Can we INVEST a task to make it smaller for the team to estimate more accurate

2. Do we have a baseline for our Estimation? Is there any inflation for the baseline after a year?

In my project, we tried to split the tasks smaller until we cannot make it unit then estimating. It's quite a bit hard at the first time when 8Sps is not too bad to implement but if we can split it into 3Sp and 5Sps tickets we will encourage our team do it even it will take effort to brainstorm and create 2 tickets rather than 1.

Also we have a baseline estimation Story Point for us to reduce the inflation when doing the estimation. Our team picks some tickets we did in the past to make it a baseline for 2, 3, 5, 8 and 13 Sps with all the explanation about the effort, complexity and uncertainty inside the ticket. Everytime we think a story is over estimate, we will compare our baseline with the ticket we are considering. The baseline will be revised after 5 or 6 months to ensure it reflect to the team's current knowledge about the project.

In addition, We also allow people to adjust the Story points if it's under/overestimated while they are implementing the story. It's quite make our chart mess up a bit, however the team can manage and gain the knowledge right away in their working rather than waiting until the Retrospective to raise the concerns.