prose :: and :: conz

I spammed Amos

Late last month, I had a long twitter conversation with none other than the venerable lover of all things code and agile: Amos King. As you can see, we eventually took the conversation offline given Twitter is not quite conducive to in-depth conversations such as how one should break software development stories into smaller stories. Furthermore, an email is also not fully sufficient and the topic evidently warranted a full one-hour podcast.

Long-story short (pun!), I was surprised to see Amos say stories should not only be shorter than a day, but ideally just a couple hours long. My team at Mentor Graphics typically works on stories that are one to three days long. That’s quite a difference! Well it turns out that I just needed a pro to help me think through my stories better. Let’s first take a look at one of our stories. For a little context, our application performs searches on a large database and presents results in a table. We currently display the first 25 results, but now we want to page those results. Here is the 8-point story:

As an engineer, I would like the ability to page through the results.

That seemed perfectly reasonable to us when we wrote it. It’s something valuable added to the system that the end user (an engineer in this case) could use. He (yes “he”. I know plenty of outstanding women engineers but I’m not interested in mangling my English to actively acknowledge this fact. “He” just means “singular human, gender not specified” in this context. If there is a better way to express this, please enlighten) can now page through all of these results. This seemed to be the minimum viable feature for solving that problem.

I now see that not only is that last statement wrong, I also have a tool to use to pry apart the smaller pieces. In the offline email exchange, Amos suggested we utilize the “Given/When/Then” format for writing stories when we need to break one down. Up to this point, we had been using the “As a ____ I want to ____ in order to ____” approach as you can see from the example. While that is effective in many regards, it tends to create stories that are larger. With the “Given/When/Then” I can bust it up into these smaller pieces:

As an engineer, GIVEN a search has been done WHEN the search is displayed THEN display the appropriate number of pages.

As an engineer, GIVEN a search has been done WHEN there is only one page of results THEN don’t display the paging.

As an engineer, GIVEN there are multiple pages WHEN the user selects a page THEN display that page and show it is selected in the paging interface.

As an engineer, GIVEN there are multiple pages WHEN the user selects next or previous THEN display the next or previous page respectively and show it is selected in the paging interface.

Now we have four stories, and interestingly enough… the points still add up to eight. I’m sure Amos would break them up more, but for us to take an 8-pointer (roughly a 3-day task) down to 4 tasks at three points or less each (at most a day each), this is good progress.

Some other good things shake out. In the original story, should there be buttons for First and Last page? Well, that is up to the interpreter of the story, the developer. After breaking it down you see that there is no room for this interpretation. Instead, the PO has clearly communicated to the team that there is not an need for the feature (at least not now). Also, we know that we should not show the paging stuff when there is only one page.

I’m looking forward to watching these tasks go across the board. Now I can take Amos’s original advice and have the team jump to the rescue if someone gets stuck more than a day on any one of these tasks.

Now some folks may object to the usefulness of each story without the others. But each one DOES add value. Take the first one. Now the user knows how many pages are available. He may not be able to view the other ones, but it is good info to know more about how many pages of results the search returned. Furthermore, the PO can already begin evaluating look and feel of the paging widget while the team continues working on the next stories. This is very valuable.

There are lots of other benefits the guys described in the podcast, so give it a listen. We’ll see how this sprint pans out, but I’m very optimistic that the extra work we did to break all of our stories down will pay off. It was laborious to practice this for the first time, but I know we’ll get better at it.

A big thanks to Amos for letting me spam him and steal some free agile coaching! (If you’re like me and find value in what they’re up to (and it IS valuable), then buy a shirt … (Here’s some more unnecessary parens for my Clojure buddies))


Amos has responded.

Olde Comments
  1. snemarch says:

    A pretty nice entry.

    Some people might find that it’s a bit “Ob Duh”, but those will be folks that have gone through estimation problems themselves, and have reached similar conclusions. IMHO it’s damn hard, and there’s no silver bullet – atomizing tasks helps, but you risk adding a lot of bureaucratic overhead.

    I find that this blogpost communicates a pretty sound balance, and GIVEN-WHEN-THEN is something I hadn’t thought about, but which might be a pretty neat formalization, and which could probably be translated to Danish decently enough.

    • barnesjd says:

      Yeah, that approach is pretty nifty. If you have an hour, listen to that podcast. It has a lot of good stuff, with this being just one application of what I learned. I agree with you regarding the risk of bureaucratic overhead. If I get my stories to a day or smaller, I’m pretty happy. Amos doesn’t want to stop until he gets them under half a day. He must use better agile tracking tools than me. :)

      If you try it out, let me know how it goes. It helped us tremendously with the previous planning. I’m anxious to see how the sprint pans out as a result.

  2. […] I spammed Amos, by Joe Barnes […]

  3. chowspecial says:

    This comes in handy if you’re writing cukes as requirements as well.

    One thing I’d like to mention is that once you have this, it becomes apparent how the backlog should then be prioritized.

  4. […] always interested in busting up big things. Big stories into smaller stories, big chunks of code into smaller ones, and certainly big applications into small configurable […]

Tagged with: web-development (19), agility (7)