Should you 'Story Point' everything?

Hi Max, 

In the Sprint Reviews, how would story points actually show that the Sprint Goal was met? I would think the stakeholders want to see the done Product Increment as evidence. That being said, I agree the value of 'pointing' things may be lost in that forecasting and planning is probably more challenging. 

If the team is not using points for things like bugs and technical items within the Product Backlog, are they estimating them at all? 

My take is typically to estimate all Product Backlog Items. If they team wants to do that in a variety of ways I'd challenge them to consider any impacts to their ability to plan and forecast PBI's. 

Now as far as i can work out, the only time that story points are looked at is in the sprint review at which point stakeholders will ask did you meet your commitment. Yes or no?

I feel like the purpose of story points is being lost. They aren't be used to keep track of the effort required to deliver "stuff" and they aren't being used to provide a guide to the team on how much they can do over our sprint period (2 weeks)... so what's the point?

The point is that estimates are being misused in order to proxy for value. They've been subverted for that purpose. It may be, for example, that releasing increments of production quality every Sprint is thought too hard. This will translate into weak pull for deliverables, and so teams "commit" to points instead, which is fakery. Hence there is little incentive to forecast how much work remains until an increment is Done.

In the Sprint Reviews, how would story points actually show that the Sprint Goal was met? I would think the stakeholders want to see the done Product Increment as evidence. That being said, I agree the value of 'pointing' things may be lost in that forecasting and planning is probably more challenging. 

Hi Tony, thanks for replying. This is something else that is missing, that clear sprint goal so i'm not surprised the team are then struggling in other areas like user stories... but that is for another thread. The team does show and discuss with the stakeholders the progress they have made in the sprint by way of a demo of each story. However ultimately if the team have completed the points they have committed too then the sprint is seen as successful.

If the team is not using points for things like bugs and technical items within the Product Backlog, are they estimating them at all? 

No, they aren't. 

The point is that estimates are being misused in order to proxy for value. They've been subverted for that purpose. It may be, for example, that releasing increments of production quality every Sprint is thought too hard. This will translate into weak pull for deliverables, and so teams "commit" to points instead, which is fakery. Hence there is little incentive to forecast how much work remains until an increment is Done.

Hi Ian, Thanks for replying. I'm not sure i 100% understand what it is you are saying but the team do release code to production every sprint, sometimes more than once, which provides some sort of value... not always customer value but something that can be tangibly measured as benefit. 

My opinion is that your answer is in your question: Should you 'Story Point' everything?

They are called story points for a reason. They are not call "Item Points". 

Ideally you should only have stories in your backlog and the technical tasks should be inside. 

Some companies add Spikes externally as they are not confident to bring stories into the sprint. This happens because it looks bad not completing your commitments.

Estimating everything in a product backlog is NOT possible. Example: The idea of estimating a bug sounds crazy to me as there is no way you can estimate complexity.

Regarding forecasting: I don't like to story point estimations very far in the backlog as that sets a wrong message that the stories are well defined, and the estimates are unmoveable.  I like better T-shirt size for anything that is further than 1 month away of my radar.  

not always customer value but something that can be tangibly measured as benefit

If there is a benefit which can be tangibly measured in a Sprint Review, why are story points being measured instead? Why are story points thought of as a team commitment?

Max,

It is critical as a Scrum Master to ensure that story points are being used properly within an organization.   They serve two purposes only: to help the Development Team and Product Owner plan future sprints, and to be accumulated for done items at the end of a sprint for velocity calculation purposes.   They are not a proxy for value delivery.

That said, it seems there are a number of different items (bugs, technical tasks, spikes) that have a capacity impact on the Development Team each sprint.   For planning purposes, if the team prefers to not point these items, a mechanism to determine the capacity impact is still desired.

Are there historical metrics around the number of items in each category that the team completes each sprint?   If so, can these categories be "guesstimated" at a certain % of capacity each sprint to be reserved for it?   Obviously, such an approach may need to be tweaked sprint by sprint in order to support the team's ability to forecast.

Ultimately, I would also want to understand what the team thinks about their ability to plan, and what strategies they might want to experiment with. 

Also, it is critical that the Development Team leverage the Daily Scrum as an inspect and adapt event as much as possible in order to understand where they are in the sprint, discuss how they are performing according to expectations, determine if the sprint goal is still achievable, and decide if anything needs to be adjusted in the sprint backlog based on their progress.

I have found, and this may depend on your team, that removing story points entirely helps the team and stakeholders focus on the sprint goal instead of "How many points". 

I experimented with this by first removing the points from the backlog items in our tool, but kept notes on the point values associated to each of the backlog items(just in case). It actually went quite well.

We got into planning and the team was surprised to see that all of them were blank. A few things happened with this:

1. The team was engaged all through out planning. They had to look at each of the backlog items, versus just going on points alone. They truly owned their sprint backlog from here on out. 

2. We focused on a goal instead of how many points can we get done. This is the first sprint we delivered a working increment instead of a partial feature. 

3. The team brought in a number close to their established velocity.

4. At the Sprint Review VP level stakeholders asked, "How many points did you complete?" This opened up the conversation with them about the misuse of story points. I had some push back but once they saw working software they backed off on the number of points completed. 

My suggestion, ditch the points for a sprint and see how it goes. You can always go back. 

Hi Javi, you could have just come over to my desk :P

They are called story points for a reason. They are not call "Item Points".

That is very true if you look at it very literally... but in my experience, Story Points have been used as a way of estimating. Maybe we should call them estimation points? 

Estimating everything in a product backlog is NOT possible. Example: The idea of estimating a bug sounds crazy to me as there is no way you can estimate complexity.

I'm not suggesting you Story point the entire backlog, maybe some T-Shirt sizing, but nothing much more taxing than that. 

I do believe that you should point a bug that has been pulled in to the sprint, so long as it doesn't relate to a current story in sprint, because story points (or estimation points :P) should incorporate effort, complexity, risk and uncertainty. If a bug is very complex or you are unclear on how to proceed, surly it should be given a high point value?

Regarding forecasting: I don't like to story point estimations very far in the backlog as that sets a wrong message that the stories are well defined, and the estimates are unmoveable.  I like better T-shirt size for anything that is further than 1 month away of my radar.  

I believe that too many avoid planning or forecasting because it's "Anti-Agile" or something like that. That to me is nonsense. You should be able to keep your customers informed on when they can expect a feature to drop. Typically i wouldn't expect 1 feature to be a whole backlog worth of work!

If there is a benefit which can be tangibly measured in a Sprint Review, why are story points being measured instead? Why are story points thought of as a team commitment?

I don't really know why they are seen as a commitment Ian to be honest. Points mean prizes? Maybe the benefit is actually too hard to articulate in another way. Not sure. 

My suggestion, ditch the points for a sprint and see how it goes. You can always go back. 

That might be an interesting approach Michael, thank you. 

I think i would have to tread very cautiously here because as mentioned, the amount of story points completed is reported. Maybe i could take the first step of hiding the field in Jira but still having the value listed against it? I  don't know.

Points mean prizes? Maybe the benefit is actually too hard to articulate in another way. Not sure. 

Then that's the problem which ought to be solved. From what you say, the team has a technical capability to deliver release quality work at least once per Sprint. However this cannot yet be leveraged using Scrum, because the business has no current means to properly account for value. The discussions you intend to have should not be about points, but rather about product ownership.

To add on to the 'points as a proxy for value' statement - I don't think it's uncommon to see some individuals in leadership value activity over outcomes. If you look at some traditional project management practices the driver was to find a way to deliver on scope, schedule, and budget. In some cases this was done with little regard to whether the right thing was being delivered over the course of the project. 

If leadership can see a number of 'points delivered' then surely the team must have also delivered value and if they deliver a certain amount of points each Sprint they will also be on schedule, or so the perception seems to be. 

I believe this could be driven by applying prior assumptions in regards to projects to things like story points. 

Hai  Story Points  are  the measurements for the effort  to be done for the userstory  tobe completed.  It is measured in numbers  only.

Usually the Story Points are Estimated by the Scrum Team  using Estimation Techniques  like  Planning Poker( using Fibonacci Sequence),  T-shirt Sizing  etc.

ONLY USERSTORIES  ARE ESTIMATED  IN   WITH STORY POINT  NUMBERS    ..

userstories  are  break down into  tasks.   These tasks  are  represented in hours.

in fact the business has no current means to properly account for value

Hi Max,

Story points are a really good topic and I already had some similar issues with my team, but the problem was to implement it. First, we started planning using hours, then we moved to story points.

In my case, I have the help of a management platform to manage the work of my team and it generates very good outputs from it, for example: Gadgets of possible delivery date, wich I use a lot to predict how much increment I can deliver in a X release (in my company the releases are dated).

Here are some points that I hope may help you somehow:

- How the story points works?

-- They work following the Fibonacci values, 1, 3, 5, 8, 13, 21, 34.

- How does my team decide the value to use in the tickets?

-- 1 (minimum): easiest work

-- 34 (maximum): hardest work

Ps.: We limited it from 1 - 34 and also we use votes from them to find the best value.

When we are using the Story Points?

- Refinement: During the refinement of the Product Backlog we are indicating story points for everything and ordering the Product Backlog list. How it can help us? With the list ordered + story points indicated, the gadget can calculate (based on my team velocity) the possible dates we'll be able to deliver the work.

- Sprint Planning: As my team already work together for more than 1 year, we have the past values that we call "yesterday weather". So, what we do? We get the "yesterday weather" and get the amount of work the sprint will have. For example: In past 3 sprints my team delivered 100, 89, 132 story points. The yesterday weather will be (100+89+132)/3 = 107. So, leaving 10% of buffer to critical problems (bugs, blockers, etc) we would plan the sprint with 97 story points

- Sprint Retrospective: Here is where we are able to analyze how the sprint was related to people, achievements, etc. So here we discuss how the story points were, how to improve the work, etc.

Do we present the story point achieved in the Sprint Review?

- No. In our sprint review we are more concerned to present the new increment to PO and Stakeholders, not the team velocity, the commitment achieved, etc.

Btw, I can be mistaken but in my experience it was really necessary to have a standard for your sprint, I mean, if you intend to plan with story points, you need to add values to all your tasks (stories, bugs, tasks, sub-tasks, etc) in order to have a clear view and be able to predict better what the sprint can accomplish.