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.
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
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.
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."