Listen Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 558 features our essay Story Points – Leave Them, Don’t Love Them.  Story Points are not evil and they may be useful in some circumstances. But like most tools, at some point, they lose focus. They have outlived their usefulness, therefore, I will leave them when at all possible.  

This week, Jeremy Berriault brings his QA Corner to the podcast.  We talked about focus. How much focus is enough and how much is too much? Mr. Berriault has an opinion and stories to back his opinion up.  (more…)

Story Points: No Parking

Story points are a planning tool that has proponents and opponents. Like most tools, story points are not prima facie evil, it is only through misuse that they are problematic.  Problems tend to occur because leader, managers, and team members have a need (or at least a very strong desire) to know when a piece work will be done, what they are going to do next, whether they are meeting expectations, and in many cases what something will cost. Story points are a relative measure, a proxy of a proxy that makes answering any of these questions with precision very difficult. The best anyone can hope for is that the answers story points provide are accurate enough and provide a coherent feedback loop for teams. This could be considered damning with faint praise, however, in the right circumstances story points are a useful tool for a TEAM. I am a proponent of using story points in three scenarios. (more…)

Story Points Are A Reflection!

Last week Anthony Mersino published a blog entry titled Story Points – Love Them or Leave Them? He ended his blog entry with the question, “What do you think?” I know it will shock some of you, but I have an opinion. An opinion born from observation, research, and hands-on experience. Story points are specific to every team that uses them. I have used and still do use story points in some very specific scenarios. To answer Anthony’s question, over the years I have migrated into the “leave them” camp with a few caveats (we will tackle those later in the week). Story Points have a litany of problems including a myriad of definitions, they are a poor tool to compare performance, they are conflated with hours, and they institutionalize bias (see The Slow End Of Story Points for in-depth discussions on these points). In the last round of articles I wrote on story points, I did not address the basic conceit at the core of story points. Story points assume that teams need to size pieces of work in order to know whether the work is too big or too risky to accomplish in a specific period of time. That assumption is wrong for any team that has worked together for more than a sprint/iteration or two and breaks its work down, plans and commits to that work, and then use the results from that sprint or iteration to improve how they work. These steps are basic activities for an Agile team. The inspect and adapt feedback loop provides an experiential platform that negates the need to have a debate over Cohn’s Numbers or an entry on the Fibonacci scale. That time is better spent discussing what the work is that is being requested by the product owner and how that work is going to be delivered. (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Now on Spotify!

SPaMCAST 525 continues our conversation about story points.  Many teams find that story points are only a partially useful tool to facilitate the flow of work within a team. Today we will highlight a behavioral fix and talk RATS.

We will also have a visit from Jeremy Berriault with a discussion from the QA Corner.  Jeremey and I talked about how the concept of a minimum viable product (MVP) impacts testing.  Check out Mr. Berriault’s blog at https://qacorner.blog/

Re-Read Saturday News
We are re-reading Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along).  Chapter 10 focuses on what when Hollywood makes a movie from Bad Blood will be a titanic battle between the indomitable Elizabeth and a career military officer, but what is really a struggle between right and wrong.

Week 8 – Who is LTC Shoemakerhttps://bit.ly/2GkbWv0

Previous Entries:
Week 1 – Approach and Introductionhttps://bit.ly/2J1pY2t    (more…)

Alternatives!

Three possible alternatives:

IFPUG function points. If you have to have a standards-based approach to sizing and comparison. IFPUG function points are the gold standard. IFPUG function points are an ISO standard and can be applied to all software types (technology agnostic). The drawbacks for using function points include the perceptions that there is a high level of overhead, counting requires too much information too early in the processes and that only highly skilled wizards can count (or approximate) function points correctly. None of these perceptions are really true, however, in some circles, the tar and feathering has stuck. (more…)

Change Behavior To Change Value

Many teams find story points only a partially useful tool to facilitate the flow of work within a team. As noted, story points are not all unicorns and kittens story points can have issues. Can story points be fixed, or better yet can story points still be useful? On the whole, story points are inherently fine if they are used with discretion and structure, to meet a team’s needs.  The words discretion and structure are code for “change”. Reforming the use of story points to make them safe again doesn’t require changing how teams assess or determine story points, but rather how people in the value chain behave once they have a number (or two).  An upfront agreement for using story points makes story points “safe.” Four attributes are useful to guide any upfront agreement on the usage of story points. The RATS criteria are:

Range – Express story points and story point metrics as ranges.  Story points are often used to express the perception of the size or value of work. Using a range to communicate both inside and outside the team mitigates the risk of falling into precision bias.

Approximate – Agree that story points represent a team’s best guess using the knowledge available at a specific time.  Knowledge will evolve as the team develops specific experience, does research and/the environment changes. Story points are not precise.

Team – Gather a team.  Story points are a reflection of a collaboration between multiple points of view. As a collaboration of a group, they can not be used to assess or measure an individual.

Separate – Separate the use of story points from answering client and management questions related to when a function will be delivered and how much that functionality will cost from facilitating the flow of work with the team.

Regardless of what a team uses story points to assess or to approximate, the output of the process is a synthesis of thinking from a group of people.  Story points represent the thought process of the team that created them, influenced by the environment they operate within. Every individual on the team needs to understand the central thread of logic followed to generate story points; however, even on a mature team, individuals will have differences which further emphasize the need to establish a RATS-”based agreement on how story points will be used to ensure healthy behavior.

How did we get to this point!

Story points were originally developed as a metaphor to give a rough answer to the question of how much functionality could be delivered in a specific period of time.  The problem is that all good metaphors are eventually abused or, worse, people forget that the metaphor is a simplification and approximation of real life. Metaphors become reality.   Three basic behaviors of leaders and stakeholders in software development (broad definition) have lead the metaphor of story points to evolve into story points as measures — something they FAIL miserably at. (more…)