SPaMCAST 753 features our essay on the impact of hierarchies on engagement and fatalism. Like most things in life, the relationship is not straightforward. Hierarchies giveth and taketh away. If you don’t get the balance right you can say goodbye to engagement, innovation, and fun at work.

We also have a visit from Tony Timbol who brings his insights on the life cycle of user stories to the podcast in his To Tell A Story column. In this installment, we talk about the “Wall of Confusion.” When stories are created and then tossed over the wall to another team even high-performing teams slip into the slow lane.

Listen Now!

Flow load has a special place in flow metrics; it is a leading indicator of value delivery as exhibited in flow velocity (throughput) and flow time. We review one experiment and propose another. In the end, you either control work entry or it controls you.

A quick advertisement:

Controlling work entry requires preparation and knowledge building to establish a path to control work entry (magic wands are normally not available), which is why Jeremy Willets and I have developed a work entry workshop. We recently delivered the workshop at the 2022 Path to Agility in Columbus, OH to rave reviews. Interested? Email us at or


This week we explore the impact of process (it really isn’t a bad word) problems in prioritization. Prioritization requires a steady hand and consistency. The process for prioritization should have more in common with a well-oiled basketball or futbol team than five-year-olds playing soccer in the schoolyard. How the moving parts work together is a process.

We also have a visit from Tony Timbol discussing freestyling user story formats in his To Tell A Story column.


Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. This week we talk about five common patterns. On Tuesday I will include the PDF in the feed to see if I can spur a discussion about other patterns.  

Play now

Tony Timbol of Agile Ready joins the Software Process and Measurement Cast this week. Tony and I have worked together in a past life, so we had a bit of fun poking at each other as we talked about user stories, Tony’s new product, Agile Ready, and entrepreneurship. Tony delivers a number of great tips, some of which I already have put to use.   


Clean Language is a technique for shaping a discussion. The questions at the heart of this approach are designed to discover and explore a person’s personal metaphor. Clean language is a very useful tool for a wide range of roles from coaching to exploring requirements and needs. Before we explore how to use this approach for developing requirements and breaking user stories down we need to cover some basic concepts.  (more…)

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 (more…)

Spider web!

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! (more…)

Handicap Indicator in Brazil


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.


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

SPaMCAST 481 will feature our essay on the Life Cycle of A User Story.  A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word ‘user story’ gets mentioned and typically by people that don’t understand (or care to understand) the concept of a user story. We zoom in from 40,000 ft down to user stories in 500 or so words!  

Read other entries on user stories by following this link:

The second column this week is from Kim Pries, the Software Sensei, Kim discusses using the Extended Backus-Naur Form as a tool to extract information out of nebulous text.

Last but not least, Jeremy Berriault brings his QA Corner to the cast.  In this entry, Jeremy discusses why QAs/testers should be given space to manage their own workflow. Jeremy has recently moved the QA Corner to

Re-Read Saturday News (more…)