The Meta of getting to Small in an Agile World

If you are Agile in the Product delivery and software development space, there is strong emphasis on thinking small.  This means decomposing work to small pieces to allow for iterative and incremental delivery and eventually the continuous flow of work. While this sounds straight-forward, in practice, it is hard because it disregards the challenging mindset shift that must occur to get people to think small. 

It is important for Agile teams, coaches, and leaders need to understand for those who have never decomposed their work to “small” size chunks, they have little idea what that means and it may take time. This article focuses on several reasons why “decomposing the work to small pieces” is challenging and the meta surrounding the concept of small.

Small is mindset shift  

Imagine that you have never considered what is small and someone says, “think small!”  This is meaningless without any context or experience in “getting to small”.  To achieve the concept of understanding small bite-sized pieces or work, there is mindset change that must occur.  Imagine if you were piloting a plane for the first time and your instructor says, you must go “fast” to take off.  What does fast enough mean if you’ve not done this before? If you only ride a bicycle, then fast may mean 25 mph (or 40 kph). However, in order to take-off, fast means 75 mph (or 120 kph) for a propeller plane and 170 mph (or 275 kph) for a jet.  There must be a strategic steps to shift the mindset to think differently that includes allowing the team time to learn and experience their way to small. 

Small is Relative 

What is “small” will be different depending on the type of work a team is doing. There is back-end, middleware, front-end work and more. Each team must gauge what is small based on their work. Also, what is small will differ from team to team and is relative to team size, talent, and experience. What is small must be specific to each team. Management must not compare sizes across teams as this will deteriorate the relative sizing for the specific teams.

  
Small is Complex 

Creative work like building new products and services (or features therein) are considered complex (per the Cynefin framework) as there are unknowns and “unknown unknowns”, ergo requiring a "probe–sense–respond" approach.  Many will translate small to days of work. But translating small to time of work disregards the complexity and unknowns of the work. In an Agile world, we consider not just effort, we look at complexity of the work (e.g., what is known and unknown), and any risks involved in the work (e.g., what skills, experience, tools, infrastructure a team has and more specifically what they don’t have.  What this means is that to identify small work, you must look at effort, complexity, and risk so it isn’t straight-forward.

Small is Imprecise 

In an Agile world, we don't pretend to think that we can have precision in our sizes. We want good sizes but we have to move away from the traditional mindset where we think we can provide accurate estimates. If it isn't correct, this is actually okay as we’ll soon learn more about the work.  When you size the work within an iteration (aka, sprint) and the iteration is done, you will quickly build a historical database of sizing and will learn more about the work.  The very next iteration, you will have learned whether you were over or under for a size and when similar type work comes along you have input for the future sizing of work.  In other words, “don’t sweat the sizing”. 

Summary

When transforming to Agile, there is a shift to to small pieces of work allowing for iterative and incremental delivery of the work. Small is challenging for teams that have not had to work decompose to small. Understanding the meta around getting to small can help coaches, teams, and leaders navigate the challenges knowing that it is a mindset shift, it is imprecise, it is relative to the work and each team, and is complex.  

Story Telling with Story Mapping

Once upon a time, a customer had a great buying experience on a website.  The customer loved how from the moment the customer was on the site to the moment they checked out a product, the process was intuitive and easy to use.   The process and design of the customer experience was not by accident.  In fact, it was done very methodically using story mapping. 

What is Story Mapping

Story Mapping is both a visual practice that provides you with an understanding of how a user might use a feature and a decomposition practice that helps you consider how you may incrementally decompose an idea. Established by Jeff Patton, the visual portion helps the team understand the customer experience by imagining what the customer process might be.  This promotes the team to think through elements of what the customer finds as valuable. 

The decomposition portion allows the team to think through a number of options which represent pieces of work (e.g. epics and user stories) on how to incrementally build the feature to gain the most feedback from the customer.  This helps both validate the value of the idea and ensures the idea is being built in a way that provides the best customer experience. 

Benefits of Story Mapping

Story Mapping is a way to bridge the gap between an idea and the incremental work ahead.  It's a great way to decompose an idea to a number of unique user stories.  What are some additional benefits of story mapping?

• It moves away from thinking of functionality first and toward the customer experience first. 
• It provides the big picture and end-to-end view of the work ahead
• It's a decomposition tool from idea to multiple user stories. 
• It asks the team to identify the highest value work from a customer perspective and where you may want the most customer feedback.
• It advocates cutting only one increment of work at a time instead realizing that feedback from the current increment will help shape subsequent increments. 

Getting started with Story Mapping

How might you get started in establishing a story map?  It starts by having wall space available to place the customer experience upon.  Next you educate the team on the story mapping process (see below).  Its best to keep to a Scrum team size (e.g., 7 +/-2), where everyone participates in the process.  Then as a team, follow these high-level steps:

• Create the “backbone” of the story map.  These are the big tasks that the users engage with. Capture the end-to-end customer experience.  Start by asking “what do users do?”  You may use a quiet brainstorming approach to get a number of thoughts on the wall quickly
• Then start adding steps that happen within each backbone.  
• From there explore activities or options within each step.  Ask, what are the specific things a customer would do here?  Are there alternative things they could do?  These activities may be epics and even user stories. 
• Create the “walking skeleton”.  This is where you slice a set of activities or options that can give you the minimum end-to end value of customer experience.  Only cut enough work that can be completed within one to three sprints that represents customer value. 

As you view the wall, the horizontal access defines the flow of which you place the backbone and steps.  The vertical access under each contains the activities or options represented by epics and user stories for that particular area. Use short verb/noun phrases to capture the backbones, steps, and activities (e.g. capture my address, view my order status, receive invoice). 

Next time your work appears to represent a customer experience, consider the story mapping tool as a way to embrace the customer perspective.  Story mapping provides a valuable tool for the team to understand the big picture, while decomposing the experience to more bite size work that allows for optionality for cutting an increment of work.  Its another tool in your requirements decomposition toolkit.