Story Points: Why Did We Get To This Point

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.

1. Trying to answer when, how long and how much. Software costs money — lots and lots of money —and takes far more time to produce than most anyone outside the industry can understand. Every business wants to plan the introduction of products and features.  If you want confirmation of this assertion, observe the frenetic activity firms have getting ready for the timeframe known as the Christmas shopping season. Failure to get to market with the right products at the right time and at the right prices is a life and death event for many companies.  In public firms every product manager is asked to predict cost and revenue streams for their products. When software is required, they inevitably ask the dreaded “when, how long and how much” questions. The answers require predicting the future and then everyone is upset when they portray story points as a precise indicator of cost and duration.
2. Measurement as a tool to manage. Management is often branded as an evil in some corners of agile.  Managers are likened to Darth Vader keeping the clones in Star Wars in line. This perception is one of the reasons that there is substantial pressure to strip management down to its barest essential. Measurement becomes the Swiss army knife of management. Story points, because they are easy to collect, are collected and applied to evaluate the output of teams and individuals.  Using story points as a measure to evaluate teams and individuals requires a shift in perceptions from a rough approximation to a measure that has accuracy and precision.
3. Conflating numbers with precision.  Numbers are precise. Story points were patterned after the famous Fibonacci Sequence in which the two previous numbers combine to create the next term in the sequence (eg. 1, 2, 3, 5 …).  Note: Cohn’s numbers, another popular story point sequence adds some imprecision in the sequence to disrupt the false perception of precision as the numbers get larger. The precision of the story point creates a precision bias (a common cognitive bias) in which the person using story points conflates precision with accuracy (and vice versa). This leads to using story points in regression equations.  The application of a number to the metaphor generates a perception accuracy that is not supported.

Story points are valuable as a tool to elicit discussion and to provide a rough approximation for how much work a team might deliver. They are not useful as a measure to support estimation or to manage or evaluate the capabilities and performance of team members.  To be useful, measures must have both the accuracy and precision needed to make useful observations. We got to the point of confusing story points with measures because story points are useful. Because they are useful, experimentation has lead practitioners to try to use them for all sorts of things. However, when we forget they are no more than a rough approximation, we are going to fail more than succeed.

 

The Slow End of Story Points

Story Points Are A Fence!

A recent discussion with a Scrum Master colleague reminded me that conversations are filled with metaphors.  Metaphors are used to simplify and represent abstract concepts so they can highlight and or offer a comparison.  According to James Geary in his TED talk from July 15, 2010, we use, on average, six metaphors a minute in conversation.  We use metaphors because they are useful. Story points are a metaphor. Story points represent a piece of work. In software, a story point is an abstraction used to talk about a piece of functional code that is not perfectly understood.  Some pieces of code are harder, bigger, take longer to complete, messier, and might not be as well understood…. the list can go on. That is why story points come in different sizes. Historically two scales have been used. Both scales are based on the Fibonacci sequence. Every person and every team has a different perspective of what story point means because it is a metaphor. However, the understanding generated by the abstraction is enough to allow team members to talk about the functionality or go get a rough approximation of what can be done by the team in a sprint or iteration.  Inside the team, the metaphor allows a conversation. Unfortunately, all useful metaphors are used and extended until their marginal utility to facilitate a conversation is reduced to zero (otherwise known as the rule – all good metaphors will be used until they are kicked to death). Story points are no different.

 

SPaMCAST 520 – Velocity and Escape Velocity, An Interview with Doc Norton

http://www.spamcast.net

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

SPaMCAST 520 features our interview with Doc Norton. We talked about his new book Escape Velocity, measurement, and why velocity isn’t generally a good measure for teams. By the time teams get to a point where story point velocity is consistent and predictable, they will have better tools that have fewer negative side effects.

Doc’s Bio

Doc Norton is passionate about working with teams to improve delivery and building great organizations. Once a dedicated code slinger, Doc has turned his energy toward helping teams, departments, and companies work better together in the pursuit of better software. Working with a wide range of companies such as Groupon, Nationwide Insurance, Belly, and JaTango, Doc has applied tenants of agile, lean, systems thinking, and servant leadership to develop highly effective cultures and drastically improve their ability to deliver valuable software and products.

A Pluralsight Author, Clean Coders contributor, frequent blogger, international keynote speaker and coach, in his spare time, Doc has been working on his latest book, Escape Velocity: Better Metrics for Agile Teams. You can find his book on LeanPub at www.leanpub.com/EscapeVelocity

Twitter: @DocOnDev

Web: http://docondev.com/

Can you help keep the podcast growing? Here are some ideas:

1. Tell a friend about the cast.
2. Tweet or post about the cast.  Every mention helps.
3. Review the podcast wherever you get the cast.
4. Pitch a column to me. You are cool enough to be listening; you deserve to be heard.
5. Sponsor an episode (text or call me to talk about the idea).
6. Listen.

Whether you do one or all six, being here is a big deal to me. Thank you!

Re-Read Saturday News
This week we continue on our journey through 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!) Today we tackle a single chapter.  Chapter 6, titled Sunny, introduces Ramesh “Sunny” Balwani to the story. Sunny, Holmes’ live-in boyfriend (the stress on the live-in part is to shine a light on just how close Holmes was to Sunny), adds another layer of toxicity to the Theranos story. The toxicity feels extraordinary but is not that uncommon when teams break down.  

Current Entry:

Week 5 — Sunny – https://bit.ly/2AZ5tRq

 

Bad Blood by John Carreyrou, Re-read Week 5, Chapter 6 – Sunny

I am continuing to tune the approach to 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!) Today we tackle a single chapter.  Chapter 6, titled Sunny, introduces Ramesh “Sunny” Balwani to the story.  Sunny, Holmes’ live-in boyfriend (the stress on the live-in part is to shine a light on just how close Holmes was to Sunny), adds another layer of toxicity to the Theranos story. The toxicity feels extraordinary but is not that uncommon when teams break down. 

 

User stories Foster Collaboration When Maintaining Legacy Applications

Step into my web said the spider to the fly!

User stories are a framework to describe who needs a piece of functionality, the goal of the piece of functionality and the benefit that the “who” part of the equation expects.  The user story does not define how that goal will be attained or every step. Every user story is a combination of a card, conversation, and confirmation (Ron Jefferies’ 3 Cs). It is a lightweight path to getting a piece of work done.  That piece of work can be a new user interface or a problem processing batch transactions. If you are going to adopt user stories for legacy or maintenance work begin with these four steps!

 

User Stories and Legacy Code

Legacy?

A common question is how user stories can be developed for legacy code or for problems that crop up in production.  The implication is that creating user stories is too hard when dealing with legacy code changes or too slow when dealing with production problems.  User stories are a core tenet for most agile approaches. User stories are a vehicle to capture nascent needs and wants in a brief container, a card.  Those needs require the parties to interact and converse in order to refine those needs into something so the need can be transformed, a conversation. During the conversation, as the understanding evolves, the team learns how they will prove that they meet the need, confirmation. In our series “Agile, Where Agile Fears to Tread” we established how we can use agile techniques for both legacy (mainframe being used as a proxy for all legacy code bases) and for maintenance.  There are a lot of reasons why some practitioners resist user stories in these two are areas.

For example, determining who the user is for legacy functionality—especially backend functionality—might be difficult. The classic format of a user story is “persona, goal, benefit”.  The persona is the user; the person that will use the functionality. While everyone can and should write user stories, product owners are often solely tasked with the role and those serving legacy systems are often proxy product owners that are not close to the business. This arrangement leads legacy teams to need to lean on more classic requirements documents and use cases with reviews and signoffs to ensure a conversation. Legacy applications often are core to the organization’s mission and are often large. The list of work required to add and enhance new features is long. Long backlogs tend to be hard to groom and prioritize, meaning that the backlog is a place for ideas to die or a place to entice people to jump the queue.

The reasons user stories are difficult for maintenance are both similar and very different than for legacy applications.  The most often quoted reasons why user stories don’t fit into the maintenance flow of work is the belief that framing the problem by identifying who is affected, what they want to be fixed and why they want it fixed takes to long.  I will let that statement just sit there. Maintenance is often different from legacy work, especially correcting defects because the user is often the one that reported the problem. In large organizations, the backlog of maintenance work and small enhancements (often masquerading as bugs) can be long and fall prey to the same grooming and prioritization issue as legacy applications.  Finally, many firms outsource maintenance support and the people doing the work are removed from deep knowledge of the business and therefore have a difficult time framing user stories including acceptance criteria.

A common problem in both scenarios (but thankfully less often every year), is that legacy and maintenance personnel are required to follow structured, gated, waterfall or, worse, ad-hoc processes. Whether the reason is familiarity with these approaches, security or contractual reasons the staged or random approaches are less friendly to using user stories.  

My knee-jerk reaction to why user stories don’t fit is a retort with a barbed tongue.  This is where it is good that my mouth and lizard brain have a filter between them because it would be easy to ask whether the person asking wants to create a requirements document to sign off before getting any feedback or would just rather start to code before considering what the change should do.  Realistically, neither make sense and I am pretty sure that is not the intent of the question. Next, we explore ideas for making user stories fit.

 

 

SPaMCAST 519 – Coaching Code of Ethics, How to Become An Agilist

http://www.spamcast.net

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

SPaMCAST 519 features our essay on a code of ethics for agile coaches. A code of ethics is a compilation of ethical principles brought together into a framework. Most professions have a code of ethics that guide their behaviors, typically guided by an association that provides credentials. I think it is time to discuss a code of ethics for agile coaches.

We also have a visit from Susan Parente, with her Not A Scrumdamentalist column.  Susan discusses how to become an agilist. It is not as easy as learning any individual set of methods and techniques. One of the places to find Susan is at S3 Technologies, LLC.

I know I promised a visit from Jon M. Quigley, but I had a minor problem with the drive and did not get the column into production soon enough to make the deadline.  

Interested in supporting the podcast? Here are some ideas:

1. Tell a friend (or better yet listen to the podcast with them) about the cast.
2. Tweet or post about the cast.  Every mention helps.
3. Review the podcast wherever you get the cast.
4. Pitch a column to me. You are cool enough to be listening, you deserve to be heard.
5. Sponsor an episode (text or call me to talk about the idea).
6. Listen.

Whether you do one or all six, being there is a big deal to me.  Thank you!

Re-Read Saturday News
This week we take a slight detour in our journey through 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!) As we have noted before, the book is at heart a cautionary tale; however, it is easy to pass the shenanigans (in private I might use stronger language) as confined to the boardroom, and therefore not something that can happen inside the boundaries of an agile team or in a department.  Ahhhh, think again. To establish the basis for this brief respite we published a review of some of the common attributes of toxic organizations and toxic leaders. It would be easy to go through both of the lists and a find points in the first six chapters and tick the attributes off almost like you were watching a slow(ish)-motion train wreck.

Week 1 – Approach and Introduction – https://bit.ly/2J1pY2t   

Week 2 — A Purposeful Life and Gluebot – https://bit.ly/2RZANGh

Week 3 — Apple Envy, Goodbye East Paly and Childhood Neighbors – https://bit.ly/2zbOTeO

Week 4 — A Reflection –https://bit.ly/2RA6AfT