User Stories – What’s in a Name?

The team was eager to launch into their first release planning exercise.  Wisely, the Scrum Master and Product Owner (PO) did not hand the team a list of already-written user stories.  They knew that while it would take the team a little more time to identify and write the basics of each story, it would pay off many times over with the understanding and ownership of the stories created by this exercise.

The PO presented the first requirement. “Team, we need to provide the back office system with a summary of the day’s sales.”

A developer on the team eagerly grabbed a sticky note and jotted down the story.

OriginalStory

While the developer’s willingness to jump in and start writing a story is exactly what the PO or Scrum Master like to see, what is wrong here?  What should the PO and Scrum Master do in response to this story?

Part of the Product Owner’s job is to make sure the team understands WHO the feature is for, WHAT it is for and WHY it is needed. This is crucial because it allows the team to understand the vision for the feature, who it will benefit, and the value that it provides. This information can spur questions from the team and provide guidance as they weigh various potential solutions. Technical teams can very quickly jump to the HOW without fully understand WHAT they are building or WHY they are building it.

We all know the template for a user story: “As a <type of user> I want <some goal> so that <some reason>”.

Right away we can see that the story does not address who the story is for. As written, the story provides at best a modest sense of the goal, but with verbiage such as “Add task in scheduler to invoke C# application” it is more about the solution that the business goal.

Lastly, one of the most powerful components of a user story is the “so that” clause. This forces the PO to justify the story’s existence. What benefit will it provide?  How will it help achieve the overall vision?  If the PO can’t come up with a “so that” clause, there is a good chance that the story is not needed or is not well-enough understood.

Recognizing this, the Scrum Master jumps in and explains this to the Product Owner and the team members. The PO gives a more thorough explanation of the story, focusing on how it will help the business. The end result:

RewrittenStory

It may not be perfect yet, but it provides much more meaningful information than the original version.  This story will trigger valuable questions from and conversation with the team and ultimately lead to a better product.

Reflections:

  • If the story title is about the technical HOW and not the business WHAT, guide the team in rewriting it so that it reflects the business need or goal and not the technical solution.
  • Don’t overlook the “so that” part of the story. It forces the PO and team to justify the story and truly understand it.

Does Agile Make Business Analysts Obsolete?

One of the most challenging aspects of adopting agile is requirements gathering and definition. The challenge is not because agile has complex methods for describing requirements, rather quite the opposite. Agile methods such as writing a user story on an index card and then relying on conversations between developers, product owners, and users to carry the story through construction might work for simple systems but breaks down when the domain or requirements are complex.

Product owners typically take center stage in driving requirements definition. These product owners, many of whom come from business units (rather than IT), cobble together various methods for capturing and communicating requirements. This is done without the benefit of understanding the difference between structured, object-oriented, test scenario-based, or other industry-standard requirements methodologies and why those methodologies came to exist. At scale, user stories on index card approaches break down, leaving team members and businesses as collateral damage.  Please do not misinterpret this as Product Owner bashing – developers are just as susceptible to thinking that they can handle complex problems without the benefit of structure.

Enter the Business Analyst. When a team is responsible for solving a large, complex problem, the business analyst works with the users, product owners and developers to root out key information. For applications through which there are significant data flows, this could mean creating (gasp!) data flow diagrams. For a highly-interactive, event-based system, this could be use case models or sequence diagrams.  A good Business Analyst possesses a skill set that many developers and product owners lack: the ability to understand the complexity of requirements and the best way to capture them.

One trap to avoid is to have the Business Analyst become the conduit (a.k.a. bottleneck) through which all communication between the users and developers occurs. This collaboration continues to be important and valuable, and the Business Analyst is involved to ensure important details are surfaced and consistent with the overall application.

Reflections:

  • A formal Business Analyst skillset is probably not  necessary for simple applications.
  • For complex applications, the Business Analyst plays a key role in ensuring that the right software is built.

Who Should Write UATCs?

Collaboration

Experienced agile practitioners take for granted that detailed requirements are captured as user test cases. For organizations transitioning to agile, this is one of the more challenging practices for them to adopt. Some product owners or business analysts still view the traditional “requirements document” as the way to capture detailed requirements. Because of their attachment to this traditional form of documentation, many resist replacing them entirely with User Acceptance Test Cases (UATCs).  They view UATCs as additional work on top of writing their traditional requirements.

UATCs better convey a sense of how the system is supposed to work by using examples rather than abstract, ambiguous business rules. In a mature agile organization, the end users are best qualified to write the UATCs.  This underscores the product owner’s role: they do not need to gather every detailed requirement – their job is to connect the development team with subject matter experts rather than being a conduit between the two.

Working Software over Comprehensive Documentation

Taken to the extreme, only the highest-level details are written down. This can work for small, simple applications. For large, complex applications, this is insufficient and quickly leads to chaos, disappointment, and frustration. The key is not avoiding writing down requirements, it is capturing them ONCE so that they can be used by product owners, developers, users, and testers and be the one living artifact besides the software.

What options do teams have for adopting the practice of capturing requirements as test cases?

1)      Developers write UATCs – while some might consider this sacrilege, in reality this is a great way to get started with UATCs and establish collaborative bonds between the development team and the end users.  Of course the developers’ initial version of these will usually only reflect what is in the acceptance criteria and what was discussed during grooming, but it provides structure for gathering more details from the users.  Users quickly see the value in this approach because the requirements are written in terms that they can understand – system behaviors. They also see the value in working directly with the developers. Product owners like this because it does not add to their workload and they quickly realize the benefits of the enhanced collaboration. One caveat: developers may need coaching about expressing things as tests and expected results since they may also be accustomed to thinking in terms of catch-all business rules rather than tests.

2)      Developers and users write UATCs together – given some starting point such as a sketch of a web page, the developers and users talk through the expected behaviors for a user story. This feels time-consuming but it directly involves the users in the process of devising the test cases.

3)      Users write UATCs – while this is UATC nirvana, it is important to remember that the developers and users still need to review the UATCs together and in detail. The test cases and end product always benefit from each group’s experience and perspective.

4)      Users and testers write automated UATCs – for applications that are able to leverage automated end user testing tools like Fitnesse, users will likely need assistance with the testing toolset, format, etc.

Reflections:

Be pragmatic about who writes the UATCs. Remember the goal: collaboration that leads to deep understanding of expected system behavior.

Normalizing Story Points Across Teams

normalized story points

On a large-scale agile project/program with multiple Scrum teams working toward the same overall goal, having user stories sized in a way that makes it easier to re-assign them from one Scrum team to another provides provides a planning and execution advantage when balancing work across teams to optimize delivery dates.

 

Before adopting a common story points scale, there are a couple of keys to consider in designing the team structures:

  • Skill sets should be balanced across teams rather than having teams that are specialized (i.e. don’t have a user interface team, a database team, a services team, etc.). This allows each team to develop entire features rather than individual layers of the application. And just as importantly, it provides flexibility to move user stories from one team’s backlog to another’s, helping to avoid any one team from becoming the critical path.
  • Once the teams are formed, the teams are kept together rather than constantly re-assigning people to different teams. The philosophy of “taking the work to the team” helps high-performing teams to continue to produce rather than paying the price associated with forming/storming/norming/etc. every time new team members are added to a team. This can be a very difficult concept for organizations that are accustomed to traditional resource leveling across a department or organization, but it critical to keeping teams operating at peak productivity.

With the team structure in place, features to be developed can then be introduced into each team’s backlog. On a project that is not constrained by a minimum feature set and go-live date (the kind that we read about in text books), the product increment is released when each team completes the features in their backlog and necessary integration/regression testing is complete. When a feature set is needed by a certain date, the project manager will seek to understand if one of the teams is on the critical path and not able to meet the forecasted code complete date. If this is the case, they may need to move some of the features or stories to another team’s backlog. In order to do this, the features and stories need to be sized in a currency that is common across all teams – story points.

On a small, single-team project, each team would be free to define what a story point means to them. On a large-scale project/program, it is important that the story points scale is the same for each team in order to facilitate balancing work across teams. This can be accomplished by identifying stories in the backlog that are representative of each story point size and making those stories known to all of the teams. Team leads then attend other teams’ backlog grooming sessions (especially in the early going) to ensure teams to not deviate from the standard.

Reflections:

  • Features and stories belong to the overall project/program, not to an individual team.
  • Sizing stories using a common story points scale makes it easier to balance work across teams.
  • Sizing stories using a common story points scale allows for consistency in project reporting such as team-level burndowns or overall project/program

Getting Started with Story Points

A mature agile team intuitively knows what a story point means in terms of the relative size of a user story compared to other stories that it has sized in the past, but how does a new team that perhaps even has people who are new to agile get started with story points? As I mentioned in another blog post, Ideal Days is a story point estimation scale that blends size with effort and degrades the backlog sizing process into a drawn-out time estimation exercise. Given that a points scale like the Fibonacci sequence that relates more to size/complexity is preferred, how does a team get started when it does not have a baseline story against which to do relative sizing?

A few things should be in place to set the stage for establishing a baseline story:

  1. Definition of Done. This should include quality assurance and user testing.
  2. Sprint length. Should be no longer than two weeks.
  3. Understanding by the team that high throughput is achieved via low work in process, i.e. having a small number of user stories in flight (being worked on and not at ‘done’) in a sprint.

Once there is a set of stories in the backlog that are small enough to pull into a sprint, the next step is to discuss and assign story points. In asking the team to assign story points for the first time, I usually tell them something like this:

Team, we know that in order to meet our sprint goals we need to get the first story in this sprint coded, unit tested, and into QA by the second or third day of the sprint. Let’s call that a three point story.

With that in mind, the team sizes the first few stories. Some might argue that we are just using Ideal Days. We are not, because executing and supporting the QA and user testing efforts are not included in the goal of getting the story to QA by the second or third day of the sprint. The other reason we are not using Ideal Days is because we only use this method for sizing the first couple of stories in the backlog. After that, all estimations are done relative to those first couple of stories that were sized, by asking whether or not a story feels bigger or smaller than those stories.

Reflections:

  •  Establish the Defintion of Done, sprint length, and concept of high throughput via low work in process before sizing stories.
  •  Size stories with the goal of getting the first story into QA within the first few days of the sprint.

Sprint Length – Does Size Matter?

RulerWhen a team that is accustomed to working on 6, 12, or 18-month long projects adopts agile practices, the prospect of planning its work every week or two is daunting. Planning the work every month might be tolerable so the team goes with four week long sprint lengths. As the team becomes more and more agile, the four week long sprints start to feel drawn out and constraining. This prompts the question, does sprint length really matter?

Smells that indicate a need for shorter sprint lengths

  1. Multiple teams on same program needing to re-sync/adjust frequently because of dependencies:

In a large program consisting of several feature teams, the work produced by one feature team often becomes an input into work done by another feature team.  For example, consider Team A and Team B. Their sprints are synchronized to begin and end at the same time to help with release planning and tracking. In any given sprint, Team A may produce something in the first part of their sprint that is needed by Team B in order to produce something else in the latter part of their month-long sprint. In theory this works, but in reality as soon as something delays Team A from delivering, Team B’s sprint commitment is jeopardized. After this happens once or twice, members of Team B will no longer be willing to commit to work with cross-team dependencies. One or two-week sprints eliminate many of those disconnects.  Team B simply does not pull an item into one of their sprints until Team A is done building the pre-requisite feature set. Because the sprint length is short, there is minimal delay between Team A finishing their feature and Team B starting their work.

Note: this does not presume that component teams (that only develop one layer of the app then hand it off to another team to develop another layer) are to blame here.  These interdependencies also occur with feature teams.

  1. Team sagging in middle of the sprint and then having a burst of energy towards end of sprint.

Teams using four week sprint lengths, in spite of the professionalism and motivation of team members, can be susceptible to waiting until a deadline looms to become focused on what is needed to close out stories. The effort and energy level may not really crank up until the latter part of the sprint. Have you ever worked with a Scrum team whose energy level looks something like the graph below over the course of a sprint?

Energy Level

This is a sign that the longer sprint length is causing the team to lose focus and/or momentum until the point when they need to “put the pedal to the metal” in order to meet the sprint objectives before the close of the sprint.

  1. Team taking on a small number of large stories.

New Scrum teams often have difficulty slicing features into multiple, smaller stories. Sometimes this is because the users are afraid that if they don’t cram all of their requirements into this one story right now then they will never have another opportunity to build the rest of the functionality. Without going into a dissertation about queuing theory (check out Little’s Law if you want more info about this), large stories have a profound (negative) impact on team throughput. One of the most tangible effects of large stories is that there may be little or nothing for the users to test until near the end of the sprint, which then results in a mad scramble to finish the stories. Not exactly a model for a sustainable pace and high quality.  Shorter sprints force teams to break large stories down into smaller pieces. Once they get the hang of it, they will size the stories so that they can deliver a steady stream of functionality to QA, the Product Owner, and users for testing throughout a sprint.

  1. Team is finding that the large number of small stories is getting hard to manage and wants to combine them into just a few large stories in each four week sprint.

For teams that become adept at breaking stories down into smaller stories, a new challenge can be that there are so many stories in a four week sprint that it becomes almost unmanageable. This is a clear signal that it is time to move to shorter sprints involving a lower number of but still small stories.

  1. Team is tinkering with what stories are in the sprint backlog due to learnings that occur early in the sprint.

What if, early in the sprint, the team learns something while working on a story that results in a new story being created that encompasses those learnings? While it is commendable that the scope of the current story was not just expanded, what is not so commendable is that often teams, especially ones working on four week sprints, become tempted to swap out another story lower in the sprint backlog for this new story because otherwise the team will not be able to address the new story for another month. Of course a constantly shifting sprint commitment is hazardous to a team’s health. A team working on two week long sprints would not need to be concerned about long delays before it can address the new story.

Nowhere to hide

Just as the initial agile adoption effort brought many organizational dysfunctions to light, shorter sprint lengths will unearth still more issues. Sporadic involvement of the product owner or users cannot be concealed in a two-week sprint. Excessive work in process, with a team that is hesitant to swarm on a small number of stories at one time, creates bottlenecks for testers, product owners and users who must focus on large number of conversations at once rather than focusing on a few at a time. Shorter sprint lengths will expose these and other shortcomings and allow a team to quickly learn and adjust its practices. Also, if the Scrum Master is wise enough know when he/she needs to let the team members fail in a sprint in order for them to learn a tough lesson on their own, the impact is muted due to the shorter sprint length.

Roadblocks

If the case for one or two week sprints is so obvious, why is it hard for some teams to adopt them? A common roadblock is stakeholder concern that more sprints will result in more “unproductive” time planning sprints, doing retrospectives, and conducting sprint reviews. The reality is that sprint planning time should correlate very closely to the number of stories in the sprint, therefore a shorter sprint = less time needed for planning. Retrospective and sprint review meetings can also be shortened accordingly.

Reflections

  • One or two week long sprints allow teams to better synchronize their efforts.
  • Small stories are that much more important with shorter sprint lengths.
  • Shorter sprints require more consistent involvement from everyone on the team, including testers and product owners.

Story Points or Ideal Days?

Fibonacci CardsSizing user stories is a key part of understanding the overall effort required to create a product release. Getting started is simple: pick a baseline story and assign a number of Story Points or Ideal Days that it will take to complete the story. Next, look at other stories in the backlog and decide whether or not they are bigger or smaller than the baseline story and by how much. Lather, rinse, repeat.

Developers coming from waterfall teams are accustomed to doing time-based estimates. Junior or intermediate level developers were usually asked to estimate functionality that was well-understood and broken down into small units of work. But in waterfall efforts, sizings done during project inception were probably done using a high-level estimation technique such as function points by a more senior analyst, lead and/or architect. Agile user stories are not necessarily well-defined or split into small stories the first time that they are sized (they will be by the time they are brought into a sprint plan). Because of this legacy of thinking in terms of hours to build, developers often revert to using a time-based estimation technique when trying to size user stories.

Before we go any further, some quick definitions:

Story points: a points scale (possibly using the Fibonacci sequence – 1,2,3,5,8,13,21,etc.) that indicates the size of a story relative to a baseline story.

Ideal days: the number of days of effort that it would take the team to get a story done if the team worked with no interruptions.

Once the team has sized the baseline story, it is ready to start comparing other stories to it and assigning points to them. But along the way, developers may develop an ‘algorithm’ for assigning Story Points. You know they have done this when one of them says, “I think that story will take 8 hours, so it’s a two-pointer.” What is happening is that the developer is doing a time estimate of their effort and reverse-engineering the story points rather than sizing the story relative to other stories. This is when the ScrumMaster needs to remind the team about the goal of sizing stories and why Story Points are a better approach than a time-based estimation approach.

Story Points are for sizing, not for time estimation. This allows teams to:

  1. Quickly size features and create a release plan without getting bogged down in implementation details. Team members are often very reluctant to provide time estimates unless they have all of the details about a feature. Being agile means that it is okay not to have all of the details up front. Developers typically are more comfortable saying that Feature B is twice as big as Feature A knowing that they won’t be held to a specific time estimate.
  2. Use Story Points in conjunction with the team’s velocity to make delivery date projections that are not as prone to decay as those using story-level time estimates. Relative sizings based on Story Points are usually fairly stable; estimates based on time can change dramatically as a project unfolds. In conjunction with Story Points, velocity is a reflection the team’s productivity and expertise. This is much easier and more flexible than trying to bake size, effort, productivity, and expertise into one ideal days number for each story.
  3. Create sizings that include all of the effort to get a story to ‘done’. Story Points include development hours, user interaction design, QA testing, etc.
  4. Prevent stakeholders from using Ideal Days estimates to calculate unrealistic delivery dates which are then mandated to the team. It is not their call how many hours per day the team spends actually working on user stories. They do not have a sense of how the mix of skills on the team or other factors will impact productivity. It is up to the team to determine how much time it can spend working on stories, and how much time it needs for grooming the backlog, doing production support, etc.

Reflections

  • The team should size the backlog without having deep, detailed requirements conversations.
  • Story Points are a way to size features without having to calculate how much time it will take to do the work.
  • Story Points are less prone to decay than Ideal Days.