Writing User Stories and Planning XP Projects
Granville
Miller
Borland
randy.miller@borland.com
[From A Practical Guide to
Extreme Programming by
Most science fiction stories, to begin
with, were exploration fantasies.
-Isaac Asimov
Introduction
Software plays a key role in many critical elements of our daily life. Of course, it is not only in our workplace, but is also in our cars, telephones, and is rapidly moving into our appliances. The applications of software are indeed truly diverse. Software is an integral part of most of the fundamental sectors of commerce including manufacturing, financial, telecommunications, order fulfillment, and the list goes on. The new uses of software are endless; we can do so much with it and basically, the sky is the limit!
Unfortunately, this diversity presents a problem to software developers. Unless we create software for people who build software systems, we are unlikely to have the expertise necessary to build great systems. For example, very few of us in the software industry can really understand what it is like to trade stock on the floor of the New York Stock Exchange. Yet, we may be called upon to build systems to aid stock traders as they embark on their daily tasks. Often, building these systems is as foreign to the software developer as traveling to a foreign country, where a different language is spoken and different customs are present, would be.
To help us navigate in this foreign country, we must, more often, rely upon the knowledge of others. The people whom we must reply upon are our customers, those who have asked us to embark upon this journey. We know how to operate the transportation; they know the way. We must journey together and as a team if we are to arrive successfully at our destination.
The Philosophy of User Stories
Prior to the invention of user stories, the most common way to capture requirements was through a specification that took a snapshot at one point in time. The probability of a system emerging from such a requirements document that meets all of a customer's expectations can be very small.
Software invisibility prevents most customers from realistically conceptualizing the system in their minds. Even if they could, communication errors would probably keep us from being able to build it from their instructions. Therefore, expectations for a system whose requirements are “thrown over the wall” should not be very high.
If we relate this analogy to our journey, we shouldn’t expect to reach our destination in our foreign country from only a set of verbal directions. The view of the countryside that someone who is very familiar with the country has, is quite different from the one that we will view. Additionally, we will probably lose half of the information in the verbal communication of that picture.
What if we had the customer in the vehicle with us as we attempted to get to our destination? We would need to create an itinerary for this journey together. There would be places that we must visit and explore on our way to the destination. However, our chances of arriving at that destination would be far greater than if we traveled alone. Our chance for mishap would be far smaller.
User stories are the itinerary for our journey. They are simple descriptions of a single aspect of our system. They are places to explore together. When we arrive at those places, our customer will tell us more about them. They will give us pointers on the historical landmarks, the fine restaurants to eat in, and the best hotels to catch a good night’s sleep. However, to achieve this fantastic journey, we need to make it together.
User Stories
At the beginning of our journey, we want to create our
itinerary. Time constraints may prevent us from being able to visit all of the
places that we might like to. Some places may just be too costly or risky (such
as the top of
This is the purpose of user stories. A user story is the smallest amount of information (a step) necessary to allow the customer to define a path through the system. Today’s systems are no longer defined in terms of a solution space in which millions of solutions are possible. Good developers create systems that are easy to navigate. Expertise in the domain allows us to understand the paths through such a system that emulate the way people solve problems there.
The customer is the author of our itinerary. To the developer, this is a foreign land. The developer operates the conveyance. The customer navigates or directs us in this journey. We know that we will have limited time, so we need to make the most of it.
The proper setting for extracting user stories is a quiet place where distractions will be minimal. Choosing a location that is offsite, away from the office is an excellent choice. The attendees should include a small group of customers who bring domain expertise and are representative of the user population. Developers of the system should also attend this meeting, as they need to learn about the system that they will be building.
Figure 1: A discussion with the storyteller
To create user stories, start with a goal of the system. For example, consider
what happens when an applicant submits a loan application. What steps does the
user take when he or she attempts to achieve the goal? Write a two or three
word name starting with a verb in the center of the top of the card. Then,
write a single step in one to three sentences on an index card. Each step
captured on an index card is a user story.
Figure 2: A sample user story
While writing the story on the index card, say it aloud. Verbalization often prompts ideas for a better, perhaps more concise user story. If you think of a better way to phrase a story after you have written it on the card, don’t worry. Index cards are cheap. Just rip up the card and write the story on a new card.
Now consider the things that can go wrong as the user attempts to reach the goal. What happens to loan applications without a social security number on them? Write the steps that can bring the user back to a successful outcome as well as those which cannot be resolved.
User stories should focus on the external behavior of the system. This is the part of the system that the customer will see. We should not have stories about writing files or storing records in a database unless we are writing file systems or a new database. If information must be kept for extended periods of time, the word, “persistence”, might be suggested by the developers.
Numbering the Stack
We call the set of cards for a given goal a stack.
When all of the stories for a given goal have been captured, number the cards
in the stack. Place the story number in the top, left hand corner. If this is
your first goal, start with “1”. Number the cards from top to bottom. If this
is not your first goal, start with one plus the number on the bottom card of
your last stack.
Figure 3: Numbering the story
When the cards have been numbered, place a rubber band around all of the stories for that goal. You should have a set of stories for each goal wrapped by a rubber band. This keeps the goals separate, which will help us when we start to plan our releases and iterations.
When you have all of the stories for all of the goals, you have your deck for the project. A deck is the customer’s current understanding of what has to be completed to build the desired system. As the customer has the right to change their mind or substitute functionality without having to pay exorbitant costs, new cards may be added to the deck at any time. Existing cards may be removed and rewritten to reflect a new understanding of the system.
Providing Estimates
Once a deck has been completed, it is time for the software development team to provide estimates for each user story. An estimate is the amount of time required for a single developer to implement the story in software. We know that we will not write production code with a single developer. We will write this software in pairs of programmers. However, for the purposes of creating a good estimate, we will pretend that we need only think that a single developer is working on it. In other words, consider a single person working from start to finish for the purposes of estimation.
Our estimates are made in story points or ideal weeks of development time. An ideal week is one where all forty hours can be dedicated to programming. Again, we know that this is impossible in real life. We dedicate time to emails, meetings, activity reports, and the other trappings of corporate life. However, this is way that we create estimates so consider a dedicated approach.
If the estimate of the cost of the story is between one and three story points (one to three ideal weeks), we write the estimate in the top right hand corner of the user story and replace it in the stack. These are the ideal user stories to work with in our project. We would ideally like the customer to write every user story so that they fall within the one to three story point interval.
However, this is not possible. Some user stories represent finer aspects of the system. They will take less than a week to create. If we find stories that will take less than a week to complete, we write a zero in the top right corner. These stories are the sand of our project.
Sand complicates release planning but makes great elements for iterations complicated by vacation or new arrivals. Sand also makes for quick development wins and can be used to deliver unexpected customer value in one of our small releases. Sand is the stuff of morale building on both the development and the customer side.
Velocity
We are now able to calculate an approximation of the total cost of the release. Before we do, let's consider two factors that will dramatically affect this calculation. First, the estimates were provided for ideal weeks. This means that they are low. While our management team would love to clear all of the hurdles that impede our team, Try as we might to allow our development team to produce an ideal weeks worth of work, there is a certain amount of overhead that prevents our team from being able to accomplish this. There are many things, including email, meetings, holidays, vacations, sick days, that just take a certain percentage of our time.
Second, there are inaccuracies in our estimates. These inaccuracies tend toward the optimistic side. While there are some exceptions, most developers want to please the customers. This leads to a desire to do more than perhaps is humanly possible. More experienced development teams, especially those experienced in XP, will tend to give more balanced estimates. Experience usually leads to the removal of inaccuracies caused by this effect.
Our best ally to bring the estimates into a realistic state (if they can ever really be in a realistic state) is experience. The experienced XP development team has a keen understanding of how many ideal weeks they can accomplish in actual weeks. The inexperienced team has no idea.
The number of stories points that can be done in an actual iteration is called the velocity. Veteran XP development teams come armed with their velocity when they begin a project. Of course, the same team that writes the code must also provide the estimates.
For those development teams without any XP experience, all is not lost. We can utilize an initial velocity understanding that it is a beginning or “straw man” velocity. After each iteration, we can adjust this velocity (and replan if necessary) to achieve a better idea of how much we can accomplish. A good velocity to start with is to divide the person weeks in an iteration by three. This means that each story will cost three times as much as initially estimated.
Velocity should be measured and tracked by the tracker. Inexperienced teams will tend to gain momentum as the project continues. Convergence on a steady state velocity usually does not occur until several iterations into the project [Beck 2001A].
The Cost of the Release
We could begin to produce a first pass at the total cost of the project. Before we go any further, we need to look at the three types of decisions that our customer team will have to make: priorities, scope, and dates. Priorities determine what functionality gets put in first. Scope determines how much functionality gets put in. Our dates determine when new releases are received and when they get deployed.
There is a chance that the customer team may not have to make any of these decisions at all. If the project is relatively small, the number of developers is large enough, and there are no deadlines, we can simply add the adjusted costs of all of the user stories. This makes life easy. However, there are very few projects that enjoy this luxury.
Establishing Priorities
For larger projects, time usually determines how much will get done. We may have a hard deadline for a new system or we may have promised a delivery in an external contract. The gold owner may have donated a certain amount of developer months and the project must be finished with this budget. Whatever the reason for deadlines, this is the way that things work in the world of software.
The customer team now has two decisions to make, scope and priority. For sufficiently large projects, we can begin to roll up the total costs for each stack (or goal). There is a good chance that the total costs of the stacks may exceed our available capacity, once they are adjusted with our velocity. If this is the case, we need to evaluate the value of delivering a project with reduced scope.
If we are still OK to proceed, we can start to prioritize functionality. Based upon these initial estimates, we can prioritize our stacks according to the needs of our customer team. Working with stacks allows us to prioritize at a macro level.
Some goals are mandatory for a working system. We can deliver a cash register without the ability to scan products and deliver a receipt. The customer team prioritizes the more important stacks should be prioritized first. The stacks that represent goals that would be nice to have can be considered later if we have development team cycles available to work on them. Any stacks that fall in-between can be grouped according to whatever criteria that the customer team wishes.
|
Stack |
Adjusted Estimate |
|
Checkout Groceries |
51 weeks |
|
Manage Inventory |
66 weeks |
|
Create Orders |
42 weeks |
|
Report Sales Volume |
18 weeks |
|
Calculate MVP Bonus |
9 weeks |
This is where the planners get involved. Given the delivery dates and the needs of the intended users, their calculators come out. Delivery dates may have to be adjusted. Scope may have to be reduced. Less important functionality may be deferred.
Developers should also consider the totals for each stack. Do they sound reasonable? Are you creating the software for an entire ATM machine in thirty developer weeks (after factoring in the velocity)? If there are ten of you, can you pull this project off in three weeks? Now is the time to speak up. Is there essential functionality missing? Are your estimates too low? If so, start out with a larger velocity.
Pair Programming
Most IS and commercial software project require the services of a development team. Typical development teams tend to consist of six to fifteen software developers. We will work in pairs to produce production level code. Research shows and our experience indicates that working in pairs is as productive as working individually. That is, we will produce as much working with another as the two of us would alone.
This means that pair programming does not affect velocity but it does affect quality. Defects are more likely to be caught with two pairs of eyes than with one. Additionally, pair programming tends to prevent some of the stresses caused by universal code ownership.
We can calculate the available developers for the project based upon the total size of our development team. Velocity will take into consideration facilitation, tracking, and architecture overhead. It will also provide for odd numbers of people in the team. This is yet another reason that we can never achieve ideal weeks of development effort.
Creating the Release Plan
We now have all of the information necessary to create a release plan. The key elements are the user stories (with estimates), velocity, and development resource. We may have prioritized our stacks to ensure that we get the essential elements in the product.
If we have some spare development cycles left in our resource pool, we may take some user stories out of the other stacks to get some parts of these elements in the releases. We may remove stories from our stacks to get partial support for certain goals in as well.
If this is your first XP project, expect this release plan to change. We may find that we can do more than we had expected. XP has a way of accelerating development teams. On the other hand, never underestimate developer optimism. We could see functionality reductions in the release. You may want to wait a few iterations before scheduling your deployment of this release.
Once you have the first cut at a release plan, it helps to capture the plan in a spreadsheet. Capturing the user story numbers, names (if any), and estimates can be valuable for tracking and replanning. The spreadsheet should be available to all of the members of both teams. The planners and trackers may want their own versions to chart the progress of the system.
Figure 4: Planning a release
Replanning a Release
Releases are big enough that we do not have to make adjustments often. However, course correction may be necessary at some point in the project. A release can be replanned for any of three reasons:
•The business has changed requiring some very large changes to the project
•The development team has a adverse change in velocity [Beck 2001A]
•The number of user stories deferred is significant [Beck 2001B]
Small changes in the business environment can be corrected by writing new user stories and steering the project in the direction of the change. However, large changes may require unanticipated system goals. A new release plan must be created.
Velocity can affect the scope of the project positively and adversely. Inexperienced teams may find that their actual velocity is such that they cannot possibly deliver the release. The symptoms of a problem are a steady increase in deferred user stories and should be brought to the customer team's attention as quickly as possible.
Velocity can change due to the departure of team members, institution of policies, environmental factors (such as blackouts), and many other factors. When the team's velocity takes a hit, the possibility of a successful release diminishes. A new release plan may be in order when the new velocity is such that achieving the release plan is no longer possible.[1]
Conclusion
Creating a release plan gives our customer team an initial understanding of the cost of the project. Projects may be abandoned at this point due to cost-benefit issues. This is the best time to abandon those projects, before everyone devotes major effort to a project that is destined to be unsuccessful.
Proceeding to iteration planning is an indicator that the customer team is committed to starting this project. This commitment is one of the most important elements of a successful project.
Over the course of the project, many things will likely change. The objectives for this system may change as the business world around us changes. Our customer understanding and conceptualization may change as they see the system come to life. Our development team's understanding of what they can and cannot do may change. This is all part of the XP philosophy, embrace change.
Bibliography
[Armour 2001] Frank Armour and Granville Miller, Advanced Use Case Modeling: Volume 1: Software Systems, Addison Wesley, 2001.
[Beck 1998] Kent Beck, "Extreme Programming: A Humanistic Discipline of Software Development", In Egidio Astesiano (Ed.) Fundemental Approaches to Software Engineering, Lecture Notes in Computer Science 1382, 1998, p. 1-6.
[Beck 1999] Kent Beck, "Extreme Programming", C++ Report 11(5), May, 1999, p.26-29, 44.
[Beck 2000] Kent Beck. Extreme Programming Explained, Addison Wesley Longman, 2000.
[Beck 2001A] Kent Beck and Martin Fowler, "Planning Extreme Programming", Addison Wesley Longman, 2001.
[Beck 2001B] Kent Beck, private communication.
[Garzaniti 1995] Richard Garzaniti, Jim Haungs, and Chet Hendrickson, "Everything I Need to Know I Learned from the Chrysler Payroll Project", Addendum to OOPSLA '97, p.33-38.
[Jeffries 1999] Ronald E. Jeffries, "Extreme Programming: A humanistic discipline of software development", Presentation at Software Development East, 1999.
[Jeffries 2001A] Ron Jeffries, Ann Anderson, and Chet ("It's Chet's Fault") Hendrickson, "Extreme Programming Installed", AddisonWesley Longman, 2001. ISBN 0-201-70842-6
[Miller 2001] Granville Miller, “Java Modeling: Holonic Software Development, Part 2”, available at http://www-106.ibm.com/developerworks/java/library/j-jmod1023/.
[Yordon 1999] Edward Yourdon, Death March: The Complete Software Developer's Guide to Surviving Mission Impossible' Projects, Prentice Hall, 1999.