YDS: When Does a Scrum Team Get Credit for the Story Point?

Today's question is all about story points. When does a Scrum Team get credit for the story points? What happens if only half the work is done? Do we get half the points? All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.

How does your team handle credit for story points? Let us know in the comments!

This is one of those Scrum Master interview questions about Scrum that can throw you off. Do you understand why partial story points make no sense? These Scrum Master day in the life questions can be tricky. Perhaps some Scrum Master training could help? Want to learn more about Scrum?

Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -

Join Ryan and Todd in a Professional Scrum Master course:

And make sure you subscribe to the channel!

DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week!

FTC DISCLAIMER: This video is not sponsored by anyone.

Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.

#scrum #agile #professional scrum

[mamarine]

"Velocity is capacity." Spot on. I needed to hear that today.

[MrAkkim]

This is another great discussion. I think every team situation is different, and not every team (Agile) ships value at the end of each sprint. Some teams ship may ship 6 weeks later depending on their project roadmap. Just my thought.

[NicolasCaron]

Points as a metric tend to create the wrong incentive for the team. It incentivises overestimating and "closing" stories instead of delivering quality and value.

[DanielLiljeberg]

I haven't listened to the episode yet but wanted to comment first and then see your take :)

We all know the "to story point or not to story point" debate and the missuse of story points etc.

When used to help teams find how much can we bring into a sprint I have often found them useful for immature teams starting out with Scrum.

In the begining I have found it useful to have the remaining estimated effort updated throughout the sprint to get some kind of number of "work done" (or more correctly "effort invested")... even though we are flexible on the "done" part here. Because more than once I have found new teams failing to actually deliver a single story in their first sprint. Which would mean 0 sp done and using that as a benchmark for their next sprint could be demotivating.

Instead we could say "ok, from out initial estimate of 20sp 8sp remain. So an effort of around 12sp is what we managed this first sprint. Let's not take that as law but keep it in mind when pla nine this next sprint.".

Then we have the conversation about why we didn't get things "done" and how we could perhaps slice stories to enable us to get them done next sprint and/or if there were organisational issues that kept us from getting stories "done".

As the team matures, becomes good at slicing PBI's and understands what the estimation is actually for I tend to see the value of actually focusing on our ability to get work "done" instead of how much was started and partially worked on.

Then one day comes the day when the team doesnt feel the need for the crutch of story points at all any more :)

But I find that this is often a journey when it comes to new teams and it can be counter effective to move to fast.

[russelljhoward]

I've seen the really dubious practice of some teams modifying the story so they can split it up and gain the points... So it looks to people external to the team that they met their goal, but in fact they didn't.

[marymiller]

I think it's not just about story points. I think this is part of a wider trend where people too much focus on the framework and being dogmatic vs. getting to done. I am noticing too much of a "let's make everything Agile!" without understanding what being Agile really means. There is still a lot of using a fish for a hammer vs. using the right tool for the job.

[rolemodel]

some conversations for less mature teams and organizations is to soften the DoD. so Quality items such as UAT is moved out of the team's realm of influence, in order for teams to get to done.

[rolemodel]

What should Scrum Masters be comfortable doing and not doing?
How to handle organizations who disagree on what the Scrum Master is teaching the Scrum Team?