YDS: Should a Scrum Team Use Story Points?

Рет қаралды 10,240

Күн бұрын

Today's question is from a viewer who wants to know whether or not a Scrum Team use Story Points? It really depends on your context and situation. Story Points can certainly be a better option than hours. Ryan and Todd also provide options to Story Points and other considerations that they take into account when deciding between story points and other options for estimation. Want to learn more about Scrum?
Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -
amzn.to/3fMpH5a
Join Ryan and Todd in a Professional Scrum Master course:
www.scrum.org/...
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

Пікірлер: 22

@sarahchan202 3 жыл бұрын

Really enjoying your videos as a new Scrum Master starting out and supporting digital delivery for the Government of Canada! Love these quick hits of knowledge, insight, and links to other great agile resources.

@AgileforHumans 3 жыл бұрын

Awesome! Thank you!

@rajadas6432 3 жыл бұрын

Great insight. I liked the fact, the discussion was balanced, more context specific. Thanks for your awesome topics.

@rgwkenyon 2 жыл бұрын

If you use story points as intended they are very powerful. Combining story points and cycle time works well to.

@michaelhandley8013 3 жыл бұрын

Can't wait for the hoodies!

@rajadas6432 3 жыл бұрын

It would be great if you can discuss on following topic. Context: A team is using scrum to maintain a product. The product in its maturity phase. Team’s typical sprint works revolves around enhancing existing features, bug fixes and code refactoring. Most often the PBIs are unrelated. Challenges: Due to the unrelated nature of the PBIs, forming a sprint goal is extremely challenging. In absence of sprint goal, daily scrum turning into siloed status meeting. Idea of using kanban was declined by people at top!! Question: In absence of goal, team is not able to realign on daily basis and that’s leading to carry over. And unfortunately, carry over is red flag . Is there anyway to form a sprint goal and rally around it? I read your book, I liked your cool ideas on forming sprint goals. But this situation demands a creative solution. Thanks in advance.

@kylewilliams6769 2 жыл бұрын

Really interesting situation! My module is a pretty similar situation but we are still doing a fair amount of new feature creation but before I was hired they started using scrum and didn’t feel like it worked for them so they switched to Kanban but then they were really struggling with organization and maintaining focus on the vision and the lack of a clear vision so they brought scrum masters back in and are now using scrumban. We are still figuring it out but I think it’s going to work really well!

@user-vk3xc8qs8n 2 жыл бұрын

I had the same problem with my project in a previous organization. They started pointing bugs. I guess someone, in another Scrum body, made a case for how one could point bugs even though our training suggested not doing that. As the project manager, I personally didn’t like it when bugs were pointed. It also made it wonky in them coming up with sprint goals. The other problem was with Sprint goals. One of the sprint goals would be to fix X number of bugs of a certain type. The ScrumMasters (who were also developers), really used story points and velocity. Unfortunately, they frequently only completed 60% of the committed work (project managers were not allowed to coach ScrumMasters, and the Agile coaches were not effective in enhancing predictability). So, I stopped paying attention to those metrics they pulled. I started using cycle time. That gave me a much more accurate picture although it wasn’t complete. Cycle time was easier to discuss with the sponsor as well since the sponsor was too high up to understand story points. They were more concerned about when the work would be done.

@himadridebnath6514 2 жыл бұрын

Great discussion ! :)

@reinholdmain 2 жыл бұрын

I expected to hear the options

@AgileforHumans 2 жыл бұрын

Flow Metrics are the recommendation: Cycle Time, Throughput, WIP Limits, and Item Age. Dan Vacanti's book - When Will It Be Done? - is a great place to start.

@osnyzinho 2 жыл бұрын

amazing! thanks!

@anthonyolaleye 2 жыл бұрын

Thanks for this video, very interesting! For those of us that still use Story points, how can we assign a Story point without relating it to hours? In my experience they are joined at the hip. Can you elaborate on this?

@AgileforHumans 2 жыл бұрын

It's really hard to avoid the comparison between story points and time. I would start here and see what's possible: kzfaq.info/get/bejne/gsV9eLCkqte2eKs.html

@archiee1337 2 жыл бұрын

When do you assign tasks to specific team members? During the planning? During the sprint?

@AgileforHumans 2 жыл бұрын

We answered the question here: kzfaq.info/get/bejne/h7dhn62HqbW7oH0.html

@MrAkkim 3 жыл бұрын

What is the best way to manage work that was started in a Sprint. But not completed at the end of a Sprint. What could be done to ensure already contributed effort is accurately reflected in the sprint that has ended?

@scottf9044 2 жыл бұрын

what is meant by "accurately reflected"? If you're concerned that individuals outside of your team won't know that any work was done...then stop worrying about that. Users are interested in completed work. Your team should be interested in completed work so they can get valid feedback. If you continually have unfinished work then discuss why. if you're wondering how to use partially completed stories in planning going forward then just use What's Left and bring that data into your Sprint Planning.

@Kezrush 3 жыл бұрын

Q: Sans Story Point, what are some other plan-it-poker like facilitation techniques have you found productive?

@dimitrismammis1108 3 жыл бұрын

Hmmm. A relative measure of complexity, where complex work is done so that the team can align and gain crossfunctional knowledge, insight, is not a bad tool or practice. There will always be people in business, whom I call numerologists; people only caring for numbers, looking into your "black box " process and trying to identify a number to exploit, to make a silly metric out of it to exert their power on the team. But as long as you are true to the common values and pillars and have gained autonomy, then tools are just tools. They should not create bad practice or intent, that is a people choice. No?

@AgileforHumans 3 жыл бұрын

If there is a practice that has good intent but continually breeds bad behavior shouldn't we look for other options? You made a good statement: "They should not create bad practice or intent, that is a people choice". I like options are easy to interpret and that don't lend themselves to misinterpretation :). However, use what works!