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.

Calculating your Team’s Target Velocity

In an Agile world, using empirical data helps a team understand their pace (e.g., in regards to the Agile Principle of sustainable pace).  Sustainable pace is a concept that attempts to identify the reasonable amount of work a team member can complete while still being able to sustain that pace indefinitely while remaining engaged, innovative, and enthusiastic.  A key question is, how does a team know the amount of work they can do?

One way to do this is to capture a team's actual velocity.  A team's velocity is the amount of work a team can do in an iteration or sprint that meets a quality criteria such as Done Criteria.  The work is usually captured in several requirements or user stories each with an estimate or size in story points. The total story points of user stories completed in a sprint is an example of a team's velocity.  I'm using story points in this article as the example.  A story point is a scope measure which is equivalent to a unit of effort, complexity, and risk associated with the work.  The question is, how does a team determine their pace or target velocity (depending on the word you want to use) for the next sprint. 

There are several ways to approach this and using the empirical data from the previous sprint’s actual velocity is a good start.  It is up to you to determine what works best for your team and context:

• The simplest way to calculate the team’s target velocity (TTV) is take the previous sprint’s actual velocity and use this as the team’s target velocity.  An example if in the previous sprint, the team's actual velocity (TAV) is 120 story points, then for the next sprint, the TTV will be 120 story points.   
• Another simple way to calculate the team’s target velocity is take the average of the previous sprint’s actual velocity.  As an example, if the previous sprints’ TAVs were 80, 90, 110, 100, and 120 story points, then divide this by 5 and the TTV will be 100 story points. 
• A more complicated way is take the previous sprint’s actual velocity, plus credit points for completed effort of unfinished work, minus points that team members will be away on holiday, vacation, training (aka, out of office).  As an example, if the previous sprint’s TAV is 120 story points, then take credit for completed effort of unfinished work as 9 (3 points for 3 unfinished user stories), minus 10% of the previous sprint’s TAV due to the Thanksgiving holiday or 12 points, bringing the total to 117 story points (=120+9-12). 

As an aside, when your team is first starting out, you will not have any empirical data or previous actual velocity to work with.  In other words, you will have to guess your team's target velocity.  However, the good news is that because the sprint is often only 2, 3, or 4 weeks long, your team will not have to wait long to learn the team's actual velocity.  This can then be used as empirical data to help you calculate your team's next sprint's target velocity.  

In whatever way you decide to calculate the team's target velocity, ensure that the previous sprints’ actual target velocity is applied in some manner to bring as much empirical data into the calculation.  Also, attempt to apply a consistent calculation from sprint to sprint.  From there, inspect and adapt as appropriate.       

Agile Problem Finder

I occasionally hear that Agile is the silver bullet and will solve all engineering problems. In some cases, someone in management heard about Agile and figured it could be a quick fix to solve the challenges within their organization. Unfortunately this is far from the truth. While Agile mindset and methods can help you adapt to customer needs and deliver more effective customer value, one key benefit that I find is that Agile shines a bright spotlight on existing problems within an organization or team.

This is where Agile methods such as Scrum, eXtreme Programming (XP), Kanban, Test Driven Development (TDD), and others can be very effective problem-finding tools. While this is not what most people think about when adopting Agile, it is a side benefit. It is important to understand that Agile methods won’t necessarily help you solve the problems that are being uncovered but they really need to be removed to achieve the value delivery and speed you are looking for. 

More often these challenges have been around for quite some time, well before Agile was introduced. In fact, management and team members have known about these issues, risks, and dependencies, but they conveniently get buried under the organizational carpet. In the Agile world, every impediment can impact the value and velocity of Agile.  Once Agile comes along, the spotlight focuses brightly on anything that gets in the way of efficient and effective delivery of customer value. What are some of areas where Agile shines the halogens onto existing problems? In my experience, I have encountered numerous challenges during the deployment Agile. Here are some examples:

• When moving to a 2 week cadence of delivery, the team bumped into organizational processes like approvals and alignment of priorities that slowed the team's ability to delivery on a faster cadence. We talked with these approval groups, shared what is agile and asked if they could work with us on a more regular basis (e.g., bring approval groups in earlier and add a Scrum of Scrums to gain alignment with dependent groups).  
• In setting up Scrum teams, it became clear that there is a lack of QA resources on the project (7 developers to 1 QA engineer). We assessed that our development to QA ratio really needs to be 5 to 3, then replaced some developers with QA engineers. Until we could hire the level of QA engineers needed, we had a few of the developers play the QA role.
• We learned that teams often don't stay together long enough to perform effectively.  Project-based company didn't allow bonding time. When the project ended, the employees are reconstituted to other project teams. We worked to have a long lived team allowing them to go through the stages of forming, storming, norming, and then performing and then stay together. 
• The team lacked trust and psychological safety. There is often a culture where trust is damaged by management actions as teams are not trusted enough to make decisions. Teams don't feel safe enough to bring up vulnerable points to more easily get over team hurdles. We implemented bounded authority so teams own their own decision-making.  
• In running incremental QA processes, it becomes clear that there is a lack of automation and, in fact, very few unit tests were ever written. We then spent some time building unit tests to provide at least 80% test coverage (we built this into our Definition of Done), then began automating the tests.
• In running continuous integration, there was a lack of understanding the branching and merging process. Developers were unaware of the importance of refreshing the private workspace with latest successfully built and approved code and also continued to retain local objects and executables in their private workspaces. An effective Checkout/Checkin process (with refresh and build and promote) was established and workspace education was conducted by the Configuration Management (CM) engineers for the team.
• In working with a legacy team, it became clear upon sizing and building functionality on existing code, that we were continually breaking other parts of the code since there was tremendous technical debt within the code base. It was learned that there was no coding standards since the beginning. We initiated a refactoring strategy with coding standards to help us reduce some of the more problematic code modules.
• In working with Product Owners (aka, Product Managers), it became clear that requirements were poorly written which led to a lot of churn between the Product Owner and the developers/QA engineers. The existing requirements list had requirements at multiple levels and it was hard to discern who the requirement was meant for. I educated the Product Owners and Scrum team members on how to write requirements in a canonical form (persona + action + business value) and the POs rewrote the requirements over time in a priority order.

For some teams that move to Agile, they can get overwhelmed by the problems that are identified by the Agile spotlight. In some cases, prior to deploying Agile, it is worth identifying the existing challenges so folks realize they are not caused by Agile. One way to do this is to understand your full end-to-end "idea to release" process. The key is to add the challenges to your issues list, prioritize them, then address them in priority order. Remember, the Agile spotlight can help you identify some of your problematic areas on the product or in the organization. Take advantage of this but be prepared to address the challenges.  What existing problematic areas have you identified when you were implementing Agile?

Agile – Its more Disciplined than you Think

Agile is known to be an adaptive mindset and approach to conduct work to better align with customer needs.  A side affect and often a myth to this is that some think Agile allows ad-hoc changes and it gets branded as being the cowboy methodology. Some folks who say they are Agile, use it as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. These cowboys know that they get away with pretending to be Agile since many folks, particularly their up-line management have little idea of what Agile really is. Other folks like to term whatever they are doing as Agile in order to be on the Agile bandwagon.

However, it is the cowboy and those that want to pretend they are doing Agile that propagated the myth that Agile is an undisciplined approach. Ultimately, these pretenders can give Agile a bad name in the organization and industry since others will believe that Agile means no process, implies an ad hoc approach, and is undisciplined.

For those that have followed the formal Agile approaches of Scrum, Kanban, eXtreme Programming (XP), Test Driven Development (TTD), and more, when done right realize fairly quickly that Agile instills much more rigor and discipline than some folks realize. Some who follow Scrum properly for instance, learn quickly that there is much more discipline than they originally thought.

One of the early introductions to Scrum is Sprint (or iteration) Planning.  Imagine every two weeks you revisit the backlog to reprioritize it, then scrub and design each story, size the work, and commit to the work for the next sprint. This is meant to be a rigorous day of really understanding the work for the sprint where typically your brain will hurt upon conclusion of this day-long session!

Now let’s visit the Daily Stand-up sometimes known as the Daily Scrum. First, imagine that you MUST show up on time. This shows your commitment to schedule and respect for others' time. Then imagine you must share 'what you did yesterday' and 'what you are doing today', and “what are your impediments” and not just to the Scrum Master but to each other. Imagine, every day this is occurring! This starts to get you into a laser focus of the work and gets you motivated to get work accomplished.  

Finally imagine that at the end of each sprint, you must have working software per the end of sprint review (aka, demo). This means that within the end of a two-week sprint, you need to build the user story (aka, requirement) into a meaningful and viewable piece of functionality for validation by customers (and you cannot show customers junk, can you?). Remember that Agile takes an empirical approach where progress is based on actual observations and data to understand progress. 

To add to this, during the sprint each story you work on has to meet the rigorous “done criteria”. Done criteria is a commitment that (for example) each story that is worked on, must be checked out, incrementally designed, coded (following appropriate coding standards), possibly code-reviewed, built, unit tested, checked-in/promoted, merged, integration built, smoke tested, and system tested. Whew, is that enough discipline for you yet? All of this within a sprint so that you can have some tangible to show the customer so that they can validate if you are meeting customer needs.

Or course there are many more rigorous Agile practices. The discipline helps with the productivity and accountability to really become an empowered team. The discipline also ensures you remain hyper focused on the work. So next time someone says Agile is undisciplined and ad hoc, it is clear that they haven't done Agile as it was meant to be, and more importantly, explain to them the real rigors of Agile when you want to have observable progress.