The story writing workshop resulted in 27 stories, which are summarized in Table 19.1. The next goal is to create a release plan that will show Lori the customer what the developers expect to accomplish and whether the site can be operational within the boss’s thirty day deadline. Because there is probably more work than can be completed in those thirty days, the developers will need to work closely with Lori to prioritize stories.
Table 19.1. The initial collection of stories.
In order to create the release plan an estimate is needed for each story. As we learned in Chapter 8, “Estimating User Stories,” the developers are going to estimate each story in story points that represent ideal time, complexity, or some other measure meaningful to the team.
It isn’t necessary to start with the first story in this list (“A user can search for books by author, title or ISBN number”) but in this case the first story is a good one to start estimating with. When Lori wrote this story, the developers weren’t sure if Lori meant that a user could search for all of these fields at the same time or whether a user could search only one at a time. Since Lori’s answer could have a big impact on the estimate, it’s worth asking her.
Naturally Lori says she wants both. She wants a basic search mode where the value in one field searches both author and title. She then wants an advanced search screen where any or all of these fields can be used in combination. Even with both search modes the story isn’t that big; but there’s such an easy division between the modes that everyone agrees to tear up the story and replace it with 19.1 and 19.2.
Story Card 19.1.
Story Card 19.2.
To estimate the stories, three programmers—Rafe, Jay and Maria—get together in a room with Lori, the customer. They bring along the story cards and a few dozen blank cards. The programmers talk about 19.1, clarify a few details on it by asking questions of Lori, and then each programmer writes his or her estimate on an index card. When everyone is done, each programmer holds his or her card up so everyone can see it. They’ve written:
Rafe: 1
Jay: ½
Maria: 2
These three developers discuss their estimates. Maria explains why she thinks this story is worth two story points. She talks about how they’ll need to select a search engine, incorporate it, and only then be able to write the screens to fulfill the story. Jay says that he’s already familiar with all likely searching options and is pretty confident about the direction they should go, which is why his estimate is so much lower.
Everyone is asked to write down a new estimate. When they’re down they again show their cards. This time the cards say:
Rafe: 1
Jay: 1
Maria: 1
That was pretty easy. Jay decided to move his estimate up and Maria was convinced that they could do the story faster than she originally thought. They now have a one-story point estimate to use for 19.1. They start writing estimates down as shown in Table 19.2.
Table 19.2. Starting to write down the estimates.
Note that Lori the customer is present while the programmers come up with these estimates but she isn’t participating by writing down her estimates. Since Lori isn’t a programmer on the project, she isn’t allowed to estimate. Further, she’s not allowed to gasp or otherwise express shock at an estimate. If she does, she’ll undermine the estimation effort. Of course, if Lori hears an estimate that sounds way out of line (either too high or too low) she may need to provide some guidance or clarification. For example, she may offer something along the lines of “I can see how that might be ten story points as you’re describing it but I think I’m asking for something much, much simpler. All I really want is …”
On to 19.2, the advanced search. The programmers again write their estimates on index cards and turn them over at the same time showing:
Rafe: 2
Jay: 1
Maria: 2
Rafe says the advanced search will take a little longer than the basic search because there’s more to search on. Jay agrees but says that since the basic search will have already been coded, it won’t take long to add the advanced search features. However, Maria points out that the stories are independent and we don’t know which story will be done first. Lori the customer says she’s not sure which she’ll want done first. She’s inclined to have the basic search done first but won’t be sure until she knows the estimate (that is, cost) of each.
After another round or two of writing estimates on cards, everyone agrees that while there is a bit more work on the advanced search than the basic search, it isn’t much and they should again use an estimate of one story point.
The next few stories are straightforward to estimate and none need to be split. The developers arrive at the estimates shown in Table 19.3.
Table 19.3. Building up the list of estimates.
The next story (“A user can rate and review books”) is a bit harder. Before writing down estimates and showing them to each other, the developers talk about this story. The rating part doesn’t seem hard but the reviews seem more complicated. They’ll need a screen for users to enter a review and maybe to preview it. Will reviews just be plain text or can the reviewer type in HTML? Can users only review books they bought from us?
Because reviews are so much more involved than just rating books, we decide to split the story. This leads to 19.3 and 19.4. The programmers estimate 19.3 as two points and 19.4 as four story points.
Story Card 19.3.
While they’re thinking about rating and reviewing books, they also consider “An administrator needs to approve or reject reviews before they’re available on the site.” This could be really simple, or it could be more involved and require the administrator to identify the reason she rejects a review or possibly email the reviewer. The programmers don’t think Lori will want anything complicated and their discussion leads to an estimate of two story points.
The next story (“A user can establish an account that remembers shipping and billing information”) seems straightforward and the developers estimate it at two story points.
Next, the developers start to estimate “A user can edit her account information (credit card, shipping address, billing address and so on).” This story is not very large but it is easily split. Splitting a story like this one is frequently a good idea because it allows more flexibility during release planning and it allows the customer to prioritize work at a much finer level. In our case, for example, Lori may think it is critical for users to edit their credit cards but she may be willing to wait a few iterations for the ability for users to change addresses. The original story is split, resulting in 19.5 and 19.6. Neither of these stories seems difficult so the programmers estimate 19.5 as ½ story point and 19.6 as one point.
Story Card 19.5.
Story Card 19.6.
This same process is repeated for each of the remaining stories. Only a few of the remaining stories are worth specific mention. First is the vague story: “A user, especially a Non-Sailing Gift Buyer, can easily find the wish lists of other users.” When asked about her intentions regarding how users could search for a wish list, Lori provides enough detail that the story can be rewritten as 19.7.
Story Card 19.7.
Next, everyone agrees to split “A user can check the status of her recent orders. If an order hasn’t shipped, she can add or remove books, change the shipping method, the delivery address and the credit card.” One story will cover checking the status of a recent order; the second story covers changing orders that haven’t yet shipped. The stories are shown on 19.8 and 19.9.
Story Card 19.8.
Story Card 19.9.
Finally, these three stories are constraints:
As constraints they influence other stories but do not require any specific coding themselves.
Table 19.4 shows all of the estimates.
Table 19.4. The complete list of stories and estimates.
