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
It was six weeks before the big deployment, and tensions were running high across the five feature teams on the project. Just as a team thought they were approaching the finish line, a slew of big and small database refactorings stalled progress. Tables were re-structured. Columns were added or renamed.
One team’s tech lead sent out an email in frustration: “This kind of refactoring of our data model has got to stop. Why are we adding these columns at this point? What is the business requirement that is driving all of these changes? Why did we not anticipate the need for these columns sooner?”
One of the database architects responded: “These changes were not anticipated sooner because this is an agile, not a waterfall, project. “
The tech lead was right to be frustrated some of the refactorings, and the database architect was partially correct that not all detailed requirements are known until close to the end of the project. The database architect was incorrect, however, about agile being the cause of the major changes to the data structures.
- Major structural changes to key entities in the database should not be necessary late in the project – even an agile project. The database architect does not need to know every detailed requirement in order to determine the structure of the data for key business entities given the nature and volume of the data and the technical platform. The data structures for a major business entity should be established before significant development begins using that entity. Some frameworks for scaling agile projects have the concept of an architectural team providing sufficient “architectural runway” for the feature development teams. The data structures are part of this runway.
- Some database refactoring, such as adding new columns, is typically what emerges late in a project when sufficient attention is paid to major structural concerns earlier. These are usually relatively easy for the teams to implement.
- Perform a cross-team assessment of the costs and benefits of refactorings before moving forward with them. Data architects do not always have insight into all of the implications of a database change across all of the layers of an application. If the schedule is tight, things like renaming columns or tables should be deferred. Yes, this is technical debt, but sometimes this is tradeoff that must be accepted in order to meet business goals.
- Build time into the project schedule to do refactorings. Expect that these will happen. Also expect that business stakeholders, especially those that control project budgets, will consider this work unnecessary and wonder why the team couldn’t do all of the database design up front. But of course that’s why we are agile – because we know that as hard as we try, we can never learn all of the requirements up front and we expect some degree of change throughout the course of the project.
As organizations adopt agile practices, there are several key skills that differentiate high-performing teams from mediocre teams:
1) Working in short timeboxes
For a team that is accustomed to delivering working code every six or eight months, two or four week long iterations can be unfathomable. But doing this is essential to the success of the project in order to get the benefits of continuous code integration into a testing environment and frequent user feedback. The sprint’s timebox forces the business stakeholders to constantly question the scope of each feature at a micro level and decide when to carve out functionality.
2) Splitting work into small pieces
The most common excuse for teams wanting to plan sprints using large user stories is that it is “more efficient” to do all of the coding work together and test it at the very end or in the next sprint. This perceived efficiency is self-deception. Successful agile teams know that they must put working code in front of their users early and often. Remember the old saying that “users often don’t know their requirements until the software fails to meet them?”
3) Communication and transparency
Old-school silos between IT, Product/Marketing, and business operations groups are an agile anti-pattern. Political games, finger pointing, and one-upmanship are a huge waste of an organization’s resources and energy. A grown-up culture of transparency allows all of these players to collaborate and solve difficult challenges. For the Scrum Master, this means posting project information in high-traffic areas of the office. More importantly, it means being open with stakeholders about the challenges that the team or project is encountering. Team members can feel secure speaking freely about impediments and project risks in a public forum without fear of reprisal. The essential skill here is knowing how to voice issues in a way that does not sugar-coat them but does set the stage for a constructive discussion.
4) Swarming, collaboration, team first
“Your side of the boat might be leaking but my side is fine” attitude just doesn’t cut it anymore. Lone gunmen need not apply. The most effective agile team members will gladly work outside of their skill sets and comfort zones if it helps the team succeed. Agile developers welcome and seek opportunities to discuss functionality with end users to understand their goals and needs. They leverage techniques such as User Acceptance Test Cases to capture and understand detailed requirements.
5) Focus and finish mindset
This is another one of those things that is counter-intuitive at first for people new to agile. Coders are used to getting all the coding tasks done so that they can get all of the stuff to the testers. Understanding that high work in process = low throughput is key. Developers working in lockstep with testers results in higher throughput, even if that means that the developers have to swarm on non-development tasks every now and then.
6) Scope negotiation
Scope negotiation means being relentless both when talking about items in the current sprint or when doing release planning. Sometimes it takes two, three, or four conversations about an item to admit that it is not really needed.
7) Talking about requirements at the right level of detail at the right point in time
Skilled agilists recognize that the conversation that happens in a user story writing workshop is at a much higher level than the conversation about a story right before that story is pulled into a sprint. They also shun detailed requirements until the sprint starts, knowing that a large collection of detailed requirements is inventory that is subject to decay.
8) Automated testing
Refactoring is a fact of life as requirements are progressively elaborated. Effective implementation of test-driven development and automated testing blunts the effort for regression testing as the application evolves.