Story points confusion

Hi Paul,

Welcome to the forum!

I am working as a developer and recently have been picking up a lot of the scrum master type tasks

So does this mean you have a Scrum Master, and you are just helping out, or is the Scrum Master role missing from your team?

The reason I ask is that Scrum is a carefully crafted framework to enable empiricism. If any part of Scrum is missing, then you might find other parts of Scrum no longer function correctly, and transparency or inspect & adapt opportunities are lost. I'd definitely recommend you read the Scrum Guide, even if you've done so already. I've probably read it more than a hundred times, and keep finding new things in there.

I have a bit of a confusion around story points as previously we have been estimating everything in days effort which is not ideal. 

What problems did such estimates cause?

There's nothing in Scrum that requires story point estimation, although it's a very common practice. I suspect the majority of Scrum Development Teams use some variation of estimating with story points.

I've also seen multiple teams tie themselves in knots about the "right" way to estimate, and topics around estimation are quite frequent on this forum, so it does seem to be a common problem.

Essentially, it doesn't matter what technique the team uses, as long as it serves its purpose. For instance, if you use story points, you might consider things like complexity, effort, risk, uncertainty or any combination of them. The Scrum Team should have a shared understanding of what an estimate means, but as the people doing the work, I would expect the Development Team to determine which factors are most relevant to them.

Stepping back from story points for a moment, it could be a good exercise to ask the team what benefits it gains from estimating. Maybe you even want to reflect on that for a couple of minutes, before reading the rest of my reply.

…

I've thought about it a lot, and I see four main benefits:

• Helping the Product Owner order the backlog in order to maximize delivered value
• Forecasting for the current Sprint (and future ones)
• Identifying misunderstandings within the team
• Splitting larger items into smaller ones (which has various benefits, such as reducing waste spent on low value parts of the work, enabling earlier delivery of the highest value, providing more frequent feedback opportunities, reducing risk, etc)

Here's a post from 2018 about estimates around complexity and time, and my answer there was written at a time when one of my teams was also experiencing a similar problem.

Can a story have a low story point rating but actually take up a long period of elapsed time?

It could be a function of time, effort, and complexity, as a team wishes.

The purpose of estimation is to help a team get its arms around how much work it can take on in a Sprint. So are team members happy to spend more time (potentially working more hours) on something that demands little effort and is non-complex?

They might be. Have you asked them what they consider to be important when determining their capacity?

Hi Paul,

Welcome to the forum!

Hi Simon, thank you for the detailed response, since starting to look into Scrum in more detail I can now see why it is difficult to master!

So does this mean you have a Scrum Master, and you are just helping out, or is the Scrum Master role missing from your team?

The Scrum master role is completely missing and as I am new to the organisation (my previous org was a lot more mature in Scrum) I thought I could try to do something to fill the gap by training and then certifying as a Scrum master.

I will definitely read the Scrum guide again, I have been dipping in and out of it since last week when I took the course, and have been reading through the course notes a lot to try to work out what I should do. 

What problems did such estimates cause?

Actually estimating in days did not cause any real issues, I was just under the impression after the scrum master course that is can be construed as a fixed delivery date and that a lot of teams use story points, another of the team members wants to start estimating story points and the team have agreed we should try it.

In terms of what the estimates for us help with, right now most emphasis would be on what work we can bring into a sprint, the reason for this is whilst someone is acting as Product Owner, it is not in the true sense of this role. They are absent from all sprint events including the sprint review, although I am trying to change this as we speak, I am writing up all of the user stories and acceptance criteria although the 'Product Owner' is supplying them and they have delegated the management of the product backlog to me.

I have a number of epics which define the order of and I have broken the first epic down into smaller stories (one of which is the work I opened this forum post around), the stories are then further broken down into sub tasks.

Here's a post from 2018 about estimates around complexity and time, and my answer there was written at a time when one of my teams was also experiencing a similar problem.

Thank you again! I have a lot to learn, and I am starting to really see that just passing the certification is the really easy part, putting all of this into practice (without further guidance) is going to really be the difficult part.

It could be a function of time, effort, and complexity, as a team wishes.

The purpose of estimation is to help a team get its arms around how much work it can take on in a Sprint. So are team members happy to spend more time (potentially working more hours) on something that demands little effort and is non-complex?

They might be. Have you asked them what they consider to be important when determining their capacity?

Hi Ian, thank you for your reply. Actually the truthful answer to your question is we haven't discussed exactly what is important and this will be the first thing we do next week. On reading your reply I do kind of see where my thinking was wrong, to base it only on complexity probably makes no sense, it would be better for us as a team to discuss what the story points mean to us and then work towards being able to convert this thinking into points and get good at estimating the number of points we can truly complete in a sprint.

Again, thank you both for the replies they have been massively helpful to me, I am really seeing the "Easy to understand, difficult to master" point being hammered home!

I can now also really see the scope of what the scrum masters in my previous employment actually did and had to contend with, its a lot more than the development team actually thought!

I have had the same discussion with my team, what exactly is a story point. Some say Story Points are all about complexity, but with that you cannot estimate on how much you can do within one sprint, right? If we take a brain surgery for example, the complexity is higher than putting a stamp on some paper. But if you have to stamp 10,000 sheets of paper, the amount of time will be fairly the same. .

So Story Points cannot just include the complexity, it also needs to include the volume of work and some risk.

And you name testing and other stuff besides the implementation. Those also need to be estimated, as you estimate the Story and the Story includes everything to reach the DoD, so everything from the DoD needs to be included in the estimate.

Thanks Tim, I later realised that basing it on complexity alone would not work because whilst a simple task might only amount to a small number of points the time to actually do that task could be quite great, and this would then mean a smaller but complex task might end up with a higher point rating but take less time. This would make estimating the amount of work we could bring into a sprint difficult.

There are still a lot of things that confuse me.. actually more now that I have undertaken the basic certifications, I guess when you start to think more deeply about something, sometimes things become less clear instead of more clear!

Actually estimating in days did not cause any real issues, I was just under the impression after the scrum master course that is can be construed as a fixed delivery date and that a lot of teams use story points, another of the team members wants to start estimating story points and the team have agreed we should try it.

There are different ways of estimating in days. One technique could be to consider ideal days. So "how long would it take if I can dedicate all of my time to it, without any distractions?" This is automatically separated from a promise, because we know ideal days almost never exist. It is just one way of providing relative sizing.

One limitation with that is each developer may feel the need to answer differently, based on their own skills.

Although a way around it would be to rephrase the question as "how long would it take the average developer in our team if they can dedicate all of their time to it, without any distractions?" or ""how long would it take if the entire team can dedicate all of our time to it, without any distractions?"

Story points makes this abstraction even easier, and the best example I can think of is comparing it to travelling between two places.

"How long does it take to get from Amsterdam to Zagreb?" depends on the capabilities and resources of the person going there. A professional cyclist going by bike will give a different answer to me (someone who cycles for fun), and my Croatian colleague who has a car and knows the route will probably give a different answer again.

But if we agree Amsterdam to Zagreb is 13 points, when asked to estimate Amsterdam to Cologne, we'll probably all agree it's around 2 or 3 points, even if we're not all able to get there at the same pace.

Then, as a team, we should be able to count these point estimates and what we've achieved in the past, and use this data to make better judgement about what can be achieved in a sprint.

The reason I'm explaining this is that story points can be useful, but can often work best if they accompany a mindset shift in the way estimates are done; and this mindset shift can also be achieved with time-based estimates, or simply using #NoEstimates, where the emphasis is on the way work is broken down, rather than comparing the sizes.

whilst someone is acting as Product Owner, it is not in the true sense of this role. They are absent from all sprint events including the sprint review,

I'll respond separately to this, because it could be a severe impediment to being successful with Scrum.

It reminds me of a place I used to work, and where I learned a great deal about Scrum; but ultimately I came to the conclusion that there wasn't sufficient buy-in from management about how Scrum could be useful to them, such that Scrum was potentially a burden in that context.

I'd strongly encourage trying to learn (as quickly as possible) how motivated colleagues (and particularly management) are to help resolve issues that are highlighted by using a framework such as Scrum; because it won't solve many problems for you by itself.

Scrum is much more likely to highlight the problems (often by making them painfully obvious), and it's up to you to solve each problem, rather than choose the easy option that simply hides it.

In this specific case, the problem might be that no-one is properly accountable for the value being delivered.