Breaking Bad Story Point Anti-Patterns

There is occasional controversy in the Agile coaching community on whether to apply Story Points on user stories. This often stems from the challenge where some think that story points are a direct replacement for estimation and an expectation of precision while others suggest that instead of story point sizing, we should focus on focusing on small pieces of work. In other words, when applying a practice (e.g., story points), a bad pattern is implemented which is opposed to the way practice is meant to be applied. This is known as an anti-pattern. Anti-patterns lead to results that are counterproductive to the intent of the practice and reduce their effectiveness. In other words, not good. 

What is Story Point Sizing? 

Before we go further, let’s take a moment to define what is a story point? A story point is a unit of measure describing the size, complexity, and risk to gauge the amount of work needed to complete a particular user story. 

Story points are also a relative measure to a specific team. Every team creates their own story point sizing framework based on the type of work they do, the skills and experience of the team, and what they personally perceive to be a small, medium, or large amount of work. The team collaboratively determines the story points for each story based on its perceived size, complexity, and risk. 

Story points are often correlated with small, medium, and large sized work. Some use the Fibonacci as it provides a numeric distribution that can be used to differentiate between sizes of work typically using 1, 2, 3, 5, 8, 13, 21. When using Fibonacci numbers, 1, 2, and 3 are aligned with small work, 5 and 8 are medium sized work, and 13 and 21 denote large pieces of work. 

Velocity is a metric that can help a team understand their sustainable pace by identifying the amount of story points of work a team can complete in an iteration. In each case (e.g., story points and velocity), this is why you should not compare the story point velocity across different teams. Story points and velocity are very specifically a team measure and should not be tampered with by those outside of the team. 

Anti-patterns of applying Story Points 

The reason there is concern surrounding applying story points is the ways it gets applied. As mentioned, story points are a combination of size, complexity, and risk of that specific piece of work (aka., user story). This means they are not meant to be used as a predictor or for accuracy. Here are several anti-patterns of story points in the way they get applied: 

• Hours-Days Effort anti-pattern - Some apply story point sizing as if it is nothing more than an estimated effort of hours and days. There is often a direct translation of number of hours and/or days and forget (or ignore) the complexity, risk, and uncertainty in the work.  
• Pretend Certainty anti-pattern - There is often ascribed a sense of certainty when applying story point sizing where it gets used to predict when work will get done. At best, it can help with understanding progress, but you would never estimate “all” of the work up front anyway as priorities (and requirements) tend to shift so it would be a waste to do so. 
• Pretend Precision anti-pattern – There is precision when using story points which isn’t appropriate. The numbers that story points represent are meant to be ball-park numbers as it is an amalgamation of size, complexity, and risk. 
• Contrived Comparison anti-pattern – Some organizations attempt to compare story points and velocity across teams even though they are relative to the team’s composition and the type of work they focus on. This is inappropriate and decreases the integrity of story points and velocity. 
• Effort Tampering anti-pattern – This occurs when someone outside of the team (usually management) attempts to influence the amount a work a team does by insisting on improvement. This impacts the integrity of the story point sizing framework and the velocity data as those are meant specifically for that team to have meaning. 
• Inflation anti-pattern – This can be the result of when someone outside of the team applies the Effort Tampering anti-pattern by attempts to make the team “work harder”. The result may be that the team inflates their numbers to ‘satisfy’ the influencer and effectively impact the integrity of the story point sizing framework. 
• Productivity anti-pattern – This is when story points and velocity get conflated as a productivity measure by those outside of the team. They are not productivity measures and will warp the intent of both story points and velocity. 

Mending Anti-Patterns  

The best way to eliminate or reduce anti-patterns, is to first understand what anti-patterns look like (see Anti-Pattern section above and search of other information on anti-patterns). Then do detective work to uncover what anti-patterns may exist. Follow this with determining an action to remove or eliminate them. You can do this through a theme-based retrospective where the focus is on identifying anti-patterns. 

Anti-patterns within an organization are more commonplace than you think. They are often due to a lack of clarity of what are story points, how they should be applied, and a lack of awareness that they are specifically a team-based measure. There may also be management or team member influence to use the practice or technique incorrectly. If too many of these anti-patterns exist, then the value of using story points as a team measure and as an instructive tool to help team gauge what is considered small diminishes.

Requirements Tree: Focusing your efforts on the highest value work

Requirement is a nebulous term.  It can mean something large like a strategy, to smaller items like features, user stories, or tasks. People often throw around the word requirement without a strong sense of the type of requirement it is or the level it belongs. It is important for clarity and common understanding across organizations and teams. Otherwise, it can be quite confusing as to which level people are discussing. 

To gain this common understand of the various levels of requirement, I recommend starting by establishing a requirements tree.  It is a structure that represents the relative hierarchy amongst various requirements elements within your enterprise. It makes it clear how requirements levels are connected. For example, a feature is a requirements element that is at the larger than a user story, so I would expect to find multiple children (aka, user stories) to the build a feature.  Think of it as your requirements lineage. 

What are advantages of creating a requirements tree? First, it ensures that requirements elements at the lower level (aka., the children) are aligned to higher level and presumably high value requirements elements. This ensures that you are putting all of your company’s effort on the highest value work. Second, it helps you determine if there are random requirements that made their way in through a back door.  Third, the requirements tree provides context of the level of requirement being discussed and traceability in the hierarchy.  

What are the various requirements elements and hierarchy? There is no industry standard group in either and they can vary from enterprise to enterprise. The key is to establish yours.  I like to start with corporate strategy and end with tasks as illustrated in the figure. 

Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level.  Using the requirement levels from the figure, here is how I describe each level.  A strategy sets  direction for the enterprise.  An idea is a high customer value and outcome-based opportunity.  An increment is an end-to-end slice of the idea to provide value and validate of the idea.  An epic is a function or feature.  A user story is a requirement that fits into a sprint of a week or two and has one persona.  A task is a very small unit of work that incrementally builds the user story. 

In addition, when you have the requirements tree and definitions of each level, you can align roles of who should be working on those levels with expectations and outcomes of each level. 

You may notice that instead of putting the strategy on top, I place it on the bottom.  I do this to represent the strategy as the trunk of the tree as this should provide guidance for how the smaller requirements elements (e.g., ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and the changing marketplace, it should guide the type of work you may consider working on. 

The key to your requirements tree is for you to establish one that makes sense for the type of work you do.  For example, if you only have one division in your company, then a division strategy isn’t necessary.  You may also work with business requirements so place them in the right level for your tree. Those that may consider creating a requirements tree are a combination of executives, portfolio, product owners, and team members.  Once crafted, it should be shared with everyone for a common understanding and a way to validate that the work at the team level is aligned with the highest value work.

Note: For more information on the Requirements Tree, read Chapter 15 of the book "The Agile Enterprise". 

 

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.  

Agile Requirements - A Promise for a Collaborative Conversation

Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit).  However, not enough is written about the key ingredient of a robust requirements process.  Some will say that when you document the requirement, you are done with the requirements process.  I content, that this is just the beginning.  The real value of a requirements process is not just writing it down, it is to begin the collaborative discussion. 

In an Agile world writing down a requirement begins the discussion between the business and engineering side.  Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins.  This discussion initiates the learning amongst the business and engineering side where the engineering side more thoroughly understands the business value of the requirement and the business side better understands the technical options of the requirement.

It goes much deeper than this.  In the old world, there is a typically only a one or few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘thrown over the wall’ to development.

I would suggest a much more robust approach starts with writing down the requirement and then continues with the fleshing-out of the requirement in a collaborative manner with the whole team.  This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement. 

From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team.  As an example, this could be in a grooming, refinement, agile release planning, or sprint planning (depending on your approach) where the highest priority requirements are discussed and fleshed-out with the team’s input.  During this session, the collaborative discussion may focus on the following: 

• Understanding why it is a high priority
• Validating/updating the User Story is in Canonical Form (or defined form)
• Understanding the business value and customer perspective
• Describing acceptance criteria
• Considering high-level technical details
• Identifying unknowns and risks (each should have an action to investigate and mitigate)
• Identifying what is out of scope
• Identifying dependencies
• Decomposing epic to user stories or each user story to tasks
• Providing high-level sizing (e.g., t-shirt sizing, story points, etc.)

As the collaborative discussion ensues (usually in a time-boxed manner), the requirement gains more clarity and robustness, where there is a team understanding of the work.  As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement.  At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue.  There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements.  Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it. 

Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach.  Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.

Personas – Getting to really know your Customers

When you are building your product, how well do you know your customers?  Can you visualize who they are?  Do you understand their motivations?  How do you know you have requirements or user stories for all of the various customer types that you have?   By knowing who your personas are for the product or solution you are building, can help you answer these questions.   

Personas represent specific users and act as examples of the types of users who would interact with it. Most products have several personas that use the product in different ways. Examples of three personas for a product are the regular user, power user, and administrator.

• The regular user uses only the basic user interface functionality.
• The power user needs more detailed interface functionality to handle more sophisticated work.
• The administrator needs back-end installation and maintenance functionality.

All three use the product differently, and different features are built for their respective needs. Personas are a powerful way to guide your decisions about functionality and ensure that you are, in fact, building functionality for each persona. Personas are a key ingredient in the way that user stories can be presented. Including the persona in a story description provides you the point of view (POV) of a user story and defines who that user story is for.

I recommend that you establish a description for each persona. This description is typically illustrated as a fictitious person that represents a real role. It will include the knowledge, experience, and activities of that role. By writing a persona as a fictitious person with a name, this makes the persona easier to imagine and relate to, as in the following examples.

Consider establishing personas for your products so that the functionality can be better understood and help you build a product that better aligns with your customer needs.  Finally, personas offer four distinct advantages. 

• The team understands the users better, which helps guide decisions about the functionality they need. 
• User stories can be written to include the persona to ensure the personas have requirements suited to them. 
• Testers can create acceptance tests and use cases that support personas. 
• Based on their personas, the Product Owner knows who can give the best feedback and therefore whom to invite to the reviews or demos.  

You can read more about Personas in the book entitled Being Agile in Chapter 17 in relation to customer reviews and demos and Chapter 18 in relation to writing effective user stories.