Why Story Points are Trash - a thread 🧵
1. Story Points are Subjective: Different people may have different interpretations of a particular story point value, leading to misaligned estimates and potential discrepancies in the overall estimation process. #estimation #noestimates
2. Story Points are Fragile: Changes in team composition invalidate relative estimation efforts. WIP impacts relative estimation efforts. Hidden dependencies impact story points.
3. Story Points are Hard to Define:
-Mike Cohn uses time: mountaingoatsoftware.com/blog/story-poi…
-Ron Jeffries uses days:
-Bloggers say capacity, effort, risk, time: peterkretzman.com/2018/10/24/quo…
WHICH IS IT!??!??!
4. Story Points Confuse Stakeholders: Non-technical stakeholders may need a clearer understanding of what story points represent, making it difficult for them to comprehend the estimates, forecasts, and projections provided by the Scrum Team. (See #3)
5. Story Points Have Limited Usefulness for Short-term Planning: Story points are often used to estimate the relative size or complexity of work but can vary wildly from Sprint to Sprint. Over a longer period, there can be planning benefits, not in the near term.
6. Story Points are a Lagging Indicator of Capacity: Capacity does not indicate performance, effectiveness, efficiency, progress, improvement, or value. The utility of story points ends when Sprint Planning is completed, and the Sprint Backlog is built (capacity).
7. Story Points Do Not Help with Workflow Policy Improvement: Story points cannot be used to identify potential bottlenecks or challenges that could impact the completion of a PBI, story, feature, or task.
8. Velocity Fails Due to the Flaw of Averages: Using the average number of story points completed, Sprint over Sprint is the definition of Velocity and is a massive mistake. The Flaw of Averages is in full effect, and an average velocity is, therefore, unreliable.
9. Story Points are Limited to Team Usage: Story Point estimates are limited to a team as they are relative and subjective. It is incredibly difficult, if not impossible, to normalize points between teams, let alone an entire organization or portfolio.
10. Why Eat Hotdogs When You Can Have Steak: Story Points are the hotdog of agile metrics. Yes, they can get the job done, but why not have the Tomahawk Rib-Eye? The Flow Metrics are far superior and more straightforward to collect and use.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Ryan Ripley ☧

Ryan Ripley ☧ Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @ryanripley

Dec 29, 2022
Reasons NOT to use #MobProgramming as a software development strategy:

1. Mob programming may only be suitable for some types of projects, teams, or initiatives. It may be more effective for certain tasks or projects but less effective for others.
2. Mob programming may not be suitable in a distributed work world because it requires a high level of collaboration and communication. To communicate effectively, geographically dispersed teams may need a significant investment in tools and infrastructure.
3. The infrastructure required for #mobprogramming may be more complex or costly than traditional software development methods.
Read 10 tweets
Dec 29, 2022
Advantage of #mobprogramming:
1. Increased collaboration on the Scrum Team - all team members are working on the task at hand, exchanging ideas, working together, and creating a shared understanding of the code and solution.
2. Transparent Codebase - team members can gain a deeper understanding of the system and code as a whole rather than just their own areas of responsibility. This entire team understanding removes "knowledge silos" and removes fragility from the team.
3. Faster Development: problems can be solved faster by working together, leading to value delivered sooner. Much of this happens through the Agile Principle - "Simplicity - the art of maximizing the amount of work not done - is essential."
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(