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.
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:
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.
- 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.
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.
- 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.
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.
Be pragmatic about who writes the UATCs. Remember the goal: collaboration that leads to deep understanding of expected system behavior.
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.
- 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