In this series you've learned about agile processes, the benefits of using them, and the requirements placed on the organization that uses them. You've also learned how different types of organizations adapt to agile development and about the different types of stakeholders and what their roles entail. The previous installment discussed applying user stories to define project requirements in an ever changing environment.
This article explains how to apply user stories with an example case about developing a Web-based financial planning tool. The application has a simple structure, and the basic functions are easy to understand. For brevity, the example is simplified, and the user stories don’t cover all functions in the system.
The team used Scrum as their development process and developed with Ruby on Rails. Ruby on Rails can be run on various platforms, such as Linux®, Windows™, and even on Java™ application servers, thanks to JRuby. Nowadays you have interesting choices for Web applications, even if your company or customer has mainly Java application servers.
The product backlog contains features and functions that the product manager wants to put in the product in the near future. In Scrum, the representative of the product management is called product owner. In our case, the backlog is a list of user stories.
On larger projects, finding a system to manage the product backlog and sprint backlog will take away a lot of the pain. In the example case, however, the backlogs were managed in a Web-based spreadsheet.
As discussed in Part 4, the following structure is a good framework for writing user stories:
As a [type or role of user] (who)
I want to [perform some task] (what)
So that I can [reach some goal] (why)
By answering the three who, what, and why questions, the user story is quite understandable. Without the "why," developers might be able to understand the functions correctly, but knowing why can make the user’s goal more obvious and might help developers find multiple ways to reach the goal.
A good user story should have several characteristics: It should be independent, negotiable, valuable, estimatable, small, and testable. For example, a reasonable size ensures that the functions focus on one requirement and can be tested to determine that it works as it should.
The following are the initial user stories for the Web application:
- As a team leader I want to:
- Register in the system to start the financial planning for my company.
- Manage the people who can edit our financial plans.
- Upgrade our subscription to get more features.
- As a user I want to:
- Maintain my financial plans.
- Modify the structure (groups and rows) of my financial plan.
- Input and modify the data in my financial plans.
- Run reports of my data to analyze the financials.
- As an administrator of the system I want to:
- See stats of the system.
- Run reports for our accounting office.
Most of the user stories answer the questions who and what, but some fail to give the reason why. The product owner prioritized the list according to his point of view, and then went to see the Scrum master.
The product owner and Scrum master went through the product backlog and picked four user stories to be discussed and possibly implemented in sprint number 1. The main purpose of user stories is for the customers (in our case, the product owner) and the development team to discuss the story and negotiate its implementation. The discussion is more important than any written document, because no amount of writing can substitute for face-to-face communication. The discussions are briefly described next.
As a team leader, I want to register to start the financial
planning for my company.
In order to save user data and later come back to it, the system needs to recognize the user. The product owner wants to run the application with a free version (with limited functions) and sell subscriptions for other versions. These versions are called plans. The user should be able to start using the system without a manual sales transaction, so registering to the systems, or signing up, is needed.
The user can add more users to access the company’s data in the system (a later requirement), so the person who registers can be treated as a manager or team leader. While registering, the user should input only the necessary information, such as name, e-mail, password, and possibly country. All other user information should be managed using user preferences later in the application.
As a user, I want to maintain my financial plans.
There can be more than one version of my budget, or the budget can consist of several budgets (for example, one for each product line). When users create a new budget, they should be able to copy an existing budget to use as the basis for the new. Making versions of a budget would be easy. The budget itself doesn’t need any more general information than its name.
As a user, I want to modify the structure (groups and rows) of my
The budget should have a user-modifiable structure consisting of groups and rows. The rows belong to a group. For example, costs (a group) contains personnel, office, and subcontractors (rows). Users should be able to modify and remove group and row titles. A row contains date-related data, so the budgeting view should be a matrix of groups and rows on the left with the months on the top. The data is an amount of money. In the future, the data could also be a formula of other rows, but that will be designed and planned later if necessary.
At this point, the product owner drew a few example screen layouts to show what the typical month-based budgeting could look like. The user should be able to scroll the months on the top to enable scrolling budgeting.
As a user, I want to input and modify the data in my financial
The product owner continued to draw sample screens and showed how the data (an amount of money) should be located on the screen. In the application there should be text boxes, like a spreadsheet, that let the user see and edit the data. The development team suggested possibilities for how this could work from a usability point of view. They agreed that during the first sprint they would try one of the suggestions and see if it worked.
You probably noticed a dependency between the last two user stories. The last one cannot be implemented before the third one is complete. This type of dependency is acceptable, because it's very hard to avoid such dependencies when you’re building a completely new application or new features that require something else first.
The last sentence of the third user story (about scrolling budgeting) was removed to become a new user story for later sprints. At this point, the budgeting view would show only 12 months, starting at the present month.
At the beginning of the first sprint, the team discussed the selected backlog items and agreed to commit on delivering those functions during Sprint number 1. The team then discussed the four user stories in detail and listed all tasks to be done.
The Sprint number 1 backlog contained the following tasks:
- Create the application frame.
- Create a simple cascading style sheet (CSS) for developers to use during development.
- Design the database for users, budgets, and budget data.
- Create database tables for users, budgets, budget groups, budget rows, and budget data.
- Validate the logic for user registration (for a ready component).
- Validate the logic for user sign up (for the ready component).
- Validate the logic for sending a forgotten password (for the ready component).
They also needed to create the functions for adding, deleting, and modifying basic budget data, such as adding groups and rows for the budget structure.
After sprint number 1 the product owner had a piece of working software to experiment with.
The product owner and Scrum master prioritized the remaining product backlog. They tentatively selected the following user stories for the next sprint.
- As a team leader, I want to manage the people who can edit our financial plans.
- As a team leader, I want to upgrade our subscription to get more features.
The product owner was keen to get certain functions for a select group of beta testers and pilot users to try after sprint number 2. The product owner wanted to get feedback from the users about the usability and urgently needed the functions.
During sprint number 3, the product owner was able to make changes for the product backlog. The fourth sprint was a short sprint to make changes in the user interface and functions.
The first sprints didn’t cover all the initial user stories. Some were left for future sprints, along with the wishes and comments from users. As the product evolves, the product owner will be able to add more user stories in the product backlog. As new sprints are being planned, the user stories are prioritized again so important features will get developed first. For example:
- In the budget view, the user should be able to scroll the months on the top to enable scrolling budgeting.
- As a user, I want to run reports of my data to analyze the financials.
- As an administrator, I want to see stats of the system.
- As an administrator, I want to run reports for our accounting office.
After two sprints, the beta testers had a working piece of software to experiment with. The product owner was quite happy with that. The software was not nearly ready to be launched, but it was a much better situation than waiting for a 6- or 12-month project to be ready.
Figure 1 shows a recent version of the application. The functions and basic concepts developed in the first two sprints, such as the spreadsheet structure, are included. There are also some new functions that were developed later, such as cash flow analysis, excel export, and reports.
Figure 1. Web application
User stories together with Scrum are good tools for developing Web applications. You walked through an actual application development case, and you saw how user stories and Scrum were used in building the application.
The discussions between the product management and development team were a crucial part of figuring out the best way to implement the requirements. The user stories were then divided into tasks by the development team. A task typically took less than a day to implement. A sprint was basically an agreed period of time to implement the tasks.
The frequent releases made it possible to deliver an early version first to the product management, and then to a selected group of beta testers for their experiments and comments. The comments were then considered to be user stories—or changes for the next sprints. The major benefit was getting something out fast, and making necessary changes according to the comments. The product management and users were able to get their wishes granted quickly.
- Check out the other parts of this series
on adopting agile development:
- Part 1, "Is agile development right for your organization?" (developerWorks, Mar 2008)
- Part 2, "Understanding the different facets" (developerWorks, Apr 2008)
- Part 3, "The role of agile stakeholders " (developerWorks, May 2008)
- Part 4, "Using user stories to define project requirements" (developerWorks, Jun 2008)
- Read Wikipedia's discussion of user stories.
- Read more about Scrum, and Adaptive Project Management Using Scrum.
User Stories Applied: For Agile Software Development
by Mike Cohn explains how to: develop flexible, practical
requirements that work; save time and develop better software that meets
users' needs; gather user stories—even when you can't talk to
users; leverage user stories as part of planning, scheduling, estimating,
- Get an RSS feed for Mikko Kontio's Architectural Manifesto
- Browse the technology bookstore for books on these and other technical
Get products and technologies
- Download IBM product evaluation
versions and get your hands on application development tools and
middleware products from IBM® DB2®, Lotus®, Rational®,
Tivoli®, and WebSphere®.
- Read what everyone is talking about in
developerWorks blogs and get involved in the developerWorks community.
- Check out Scott Ambler's blog - Strategies for Scaling Agile Software Development.