When Don’t I Use A Story Map

Map!

In response to the recent articles on story mapping, I was asked, “When don’t I use a user story map?” As with many powerful tools, it is easy to want to use story maps in almost every situation; however, there are a few scenarios where story maps are at best overkill or at worst might be wasted overhead.

Small, low complexity efforts. Work that only impacts a small piece of functionality rarely needs the overhead of a story map.  While every team/person has a different perspective on what is small or low complexity, I suggest one basic rule, if the output of the work is a product, feature or application, however small, create a story map to guide the work.

Disjoint accumulations of work. A classic approach in many development organizations is to gather several pieces of work together (often only loosely related) and then to call that work a project.  The whole package might be large and/or highly complex; however, the lack of cohesion between each piece of work is a problem. Creating a story map in this scenario makes little to no sense.

Operational work. A story map for installing servers or scanning documents does not make sense.  In operational scenarios value stream or process mapping are significantly more useful.

A request to all blog readers and podcast listeners –
Starting next week we are going to start a process of picking both the most overused and favorite agile saying.   I have a list, but before we start, if you have a favorite please add it to the comments or email it to tcagley@tomcagley.com.

 

Revisiting User Story Maps

Story Map

Information Radiators are one of the most powerful concepts championed in agile as communication vehicles.  In many organizations, the use of information radiators has waxed over the past few years as more and more tools have locked data into monitors and tablet screens.  As electronic tools have replaced paper, putting radiators where people can see information, as they work or walk by, has been replaced by instant access (which is code for never looked at).  Product and sprint backlogs locked away into tools have the same problem as burndown charts, cycle time scatterplots or work in process aging charts that are in a tool and never looked at. Instead of locking backlogs away, create and use agile story maps to increase transparency and improve access to information. The goal of a Story Map is to present the big picture of a product or feature for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases.  Like other information radiators, the use of story maps has changed over over the last decade as the use of agile has become more mainstream and less tied to the principles in the Agile Manifesto. Over the next few entries, the Software Process and Measurement blog will revisit story mapping and explore several usage issues in today’s software development world. Before we dive into the hard parts, though, we need to revisit creating a story map.

Story mapping is a relatively simple process for visualizing and organizing a product backlog (the hard part is generally getting the initial set of features and stories). Story mapping was identified and popularized by Jeff Patton. The story map is a multidimensional representation of a product (we will talk later in this series about whether story maps work if you are not working on a product).  Looking at a map from top to bottom, large items—epics or features—are placed at the top of the map. TIme or the user’s journey through the product is used to arrange the epics or features from left to right. For example, some of the features in a users journey for a product to sell books might include book search, book page, shopping cart, and shipping. This is sometimes known as a walking skeleton.

After the features have been arranged across the top of the map, user stories and enablers are arranged below the feature in “priority” order. Priority can be influenced by value or the order in which product owners and product managers want the software delivered (minimum viable product and/or release planning). For example, the epic “buy a book” might include a feature “shipping” which might include stories such as “search for shipping methods”, “display estimated shipping cost”, and ‘select shipping method’.

In July 2013 we described a simple process for capturing epics and building a story map.  Story maps are a simple visual representation of work. Real life adds significant complications to the mix, such as distributed teams and work that is less product or feature-oriented.  Deciding the right scenarios to use story maps should be part of every agile team’s workflow.

 

SPaMCAST 523 – Goodbye To Story Points, Centers of Excellence, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 523 features our essay on story points.  Story points were a tool designed to give teams a rough understanding of their flow of work. It was a great idea at the time, but that time has passed. Unfortunately, story points now are being used improperly creating more problems than they solve.

In addition, Jon M Quigley brings his Alpha and Omega of Product Development to the cast. In this installment, Jon discusses the risks of Centers of Excellence.  They are another great idea that can and has been ill-used by many in the industry.

Re-Read Saturday News
We are back with Chapter 7 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!). Chapter 7, titled The miniLab, focuses on overpromising and continues to layer on toxicity to the Theranos story.

Week 6 – The miniLab –  https://bit.ly/2rfmwJh

 

Guest Post: Why an Agile Center of Excellence is a Really Bad Idea

Today we have a guest post from Anthony Mersino. Anthony and I have worked together numerous times.  I respect his vision, wisdom and dry humor.

Many organizations create an organization to help with their agile transformation. Various names have been given to these groups. Two that I really don’t like are the Agile Center of Excellence and the Agile PMO. The name is not inconsequential. Here is why I think that establishing a Center of Excellence for Agile is a really bad idea.

The intent of a group like the Agile Center of Excellence is often described as ‘to promote agility in the organization’. That sounds like a good thing, right? What often happens is that the way they go about it actually inhibits agility. What frequently happens is that the Agile Center of Excellence (CoE) focuses almost entirely on standardizing processes and tools, and leveraging scale and efficiencies. What could go wrong?

 

Three Practical Alternatives to Story Points

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.

 

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