The Importance of Context
User stories are the perfect tool for maximizing development throughput by keeping things manageable and separate. You should strive to write good stories that are small and can be prioritized and negotiated independently
. Indeed, implementation strategy often goes to great lengths to avoid interplay between stories so that you can build things in parallel and not introduce a dreaded dependency.
However, there is a hidden risk associated with managing and communicating software creation solely through a collection of independent stories. Users don't judge software based on individual features; they experience the whole product and form their opinions based on this overarching experience. As the saying goes, "The whole is greater than the sum of its parts."
The Agile team's job is to figure out which solution is most suitable for users by understanding them and their context of use. This is the domain of UCD.
User stories provide Agile projects with independence and flexibility. A team can scribble a sentence on an index card to capture some thoughts about a product goal, drop it into the backlog, and then prioritize and refine it later. Because the team can swap stories around for implementation at almost any point, it is easy for the overall feel of the software to become fragmented. The implementation can jump from one section of the system to the other even within a two-week sprint.
All this agility makes it hard to retain a holistic vision of the solution. So, although the order in which a team delivers stories to the product owner is flexible, allowing the team to deliver the stories perceived as having higher value earlier, the team risks reducing the overall value of the software by providing a disjointed user experience.
To illustrate the importance of context when designing a solution for a user story, consider the example of building a project management tool for software development. Here is an example story from a manager who will use the tool:
As a manager
I want to know if a story is running over its estimated time
So that I can proactively find out what the problem is and see if there is anything I can do to help.
This sounds like a pretty good story. It's fairly independent, it is certainly negotiable, it is valuable, it is probably estimable, and it seems small enough and testable. So what's the solution? Perhaps you can run a batch process that checks if a story recorded in the database has passed its estimated time. Perhaps you should show overdue stories on the manager's home page. Maybe it would be better for everyone who accesses the system to see overdue stories. What is the simplest thing that could possibly work? Which solution can you deliver earliest to the product owner to start realizing business value?
Now consider the following possible contexts of use:
- Context 1: The manager has a portfolio of projects. She drops in to see the team once a day to check on progress and gets a demo of the application most weeks. Maybe a way of printing out a report of stories that are at risk would be useful. She could to take the report along to the daily progress updates.
- Context 2: The manager is running a couple of projects with distributed teams in different time zones. She rarely gets to meet all members of the team face to face, but keeps a good relationship with a few key members of the team. Work is scheduled in phases, such as analysis, design, implementation, test, and release. This manager probably does not know what is going on day to day on the project, so she could benefit from some form of periodic update that would prompt her to get in touch with one of her teams.
- Context 3: The manager spends all her time on this one project. She spends most of her time in the same office as the team, providing background for stories and dealing with issues that the team are having. This user may want no notification at all. She relies on day-to-day conversations to identify whether a particular story is running over. All the information she needs comes from the daily standup meetings, and overruns are recorded on the wall. Highlighting overdue stories on the system may actually be counterproductive to her team.
Given the contexts of use (i.e., who the user is, what her activities are, and the context of those activities), you are able to make better implementation decisions. If you are building specific software for one of these users, then the solution is fairly straightforward. If you are developing a larger product that could meet all of these needs, you now understand the different contexts of use for different users and can start to see that a one-size-fits-all solution may not be appropriate.