Story Points – A Behavioral Fix

Change Behavior To Change Value

Many teams find that 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.  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.

 

SPaMCAST 521 – User Stories and Legacy Code, Software Catechism, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 521 features our essay on user stories and legacy code.  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.

This week we also have a visit from the Software Sensei, Kim Pries!  Kim talks about training in a column titled, “Software Catechism.”

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 everyone that helps get the podcast and blog together. Thank you!

Re-Read Saturday News
The Software Process and Measurement Cast and Blog crew is on the road this weekend so we are going to take a day off from our re-read of 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 re-visit an entry from 2013, In 2013 we ran a series titled “Motivational Sunday”. In this entry, we talked about the relationship between commitment and habits. I have tweaked the works a little but the sentiments are no different.

Habit and Commitment – https://bit.ly/2KbKq13

 

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.

 

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.

 

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!

 

SPaMCAST 513 – Reciprocity and Passengers, Self-directed Teams, Hard Deadlines, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 513 features a second essay on reciprocity.  One of the hardest lessons I have had to learn is that some people on a team are passengers and others play different, more involved, roles. Being a passenger long-term on a team or in an organization is a form of rent-seeking and is not valued highly by others.

We also have columns from Susan Parente (I Am Not a Scrumdamentalist) and Jeremy Berriault (QA Corner).  Susan provides a spirited discussion of self-directed teams in agile.  It is a myth that agile teams just get to do what they want. One of the places to find Susan is at S3 Technologies, LLC. Rounding out the cast is this month’s installment of the QA Corner.   Jeremy discusses one of thorniest facts of life for a tester — hard deadlines.

Re-Read Saturday News

This week we tackle Chapter 8, titled The Hero In The Age of Checklists.  Heroes are a big deal; pick up any newspaper and you will see how much the cult of hero is celebrated.  Checklists and methods are viewed by many as diminishing the role of the hero which sows the seeds of resistance to change.  What role does the hero play in a disciplined process? If the hero is core to how we view ourselves and our society, do tools like checklists run the risk of being met with hostility?  Chapter 8 dives directly into the deep end to address these topics.

We have two or three more weeks left in this re-read, which means it’s time for the poll.  Vote and be heard! Write in candidates are welcome.

Remember to buy a copy of The Checklist Manifesto and READ along!

Current Installment:

Week 9 – The Hero In The Age of Checklists – https://bit.ly/2PWu2TC

 

 

SPaMCAST 508 – Product Owners and Scrum Masters, An Interview with Vasco Duarte

http://www.spamcast.net

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

SPaMCAST 508 features our interview with Vasco Duarte!  Vasco and I discuss vision and product owners. The product owner role is crucial. To be effective, the product owner must be able to articulate a vision for the product they champion.

Vasco Duarte’s Bio in his own words:

I want to transform product development organizations into product business organizations. I do that by focusing the work of the product development teams on the end-to-end life-cycle of their products. From Concept to Cash and Back!

Currently a Managing Partner at Oikosofy.

Product Manager, Scrum Master, Project Manager, Director, Agile Coach are only some of the roles that I’ve taken in software development organizations. Having worked in the software industry since 1997, and Agile practitioner since 2004. I’ve worked in small, medium and large software organizations as an Agile Coach or leader in agile adoption at those organizations.

I was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia, and F-Secure.

I host a daily podcast where I interview Scrum Masters about their daily challenges and insights: https://scrum-master-toolbox.org/

You can read more from me at my blog: http://SoftwareDevelopmentToday.com

You can join me on twitter: @duarte_vasco

Re-Read Saturday News

In week 4 of re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along) we tackle Chapter 3, The End Of The Master Builder.  In Chapter 3 Gawande identifies the scenarios in which checklists have an impact.  Checklists provide value even in the most complicated scenarios.

Current Installment:

Week 4 – The End Of The Master Builder – https://bit.ly/2BmIGBc