Breaking Stories Down

When I've talked to various people about the art of writing stories they often say that they have trouble breaking them down into small enough pieces. One former colleague who now works for a gaming company told me that their stories were not far off being 'build a game'. I'm not sure why this is. I think maybe people know that a story should describe a discrete piece of functionality, and deliver value to a user, but they come up with things in terms of a traditional end-to-end use case, like 'user buys a book'.

Now, 'user buys a book' is a huge epic of a story. On any bookstore site you've got the page which displays information about the book, you've got several screens of complex shopping cart functionality, you've got email receipts, hooks into the backoffice, etc. Starting at the beginning, your first story might be 'Show book information'. Suppose your UI prototype is this screenshot from Amazon:



There's an awful lot going on just on that page. What's the most basic information you could include in 'Show Book Information'? How about the title, author, and perhaps the front cover image? That will do for our first story. I would actually photoshop my screenshot and stick it to the front of the story card:



While my acceptance criteria would look like this:



There's a number of things to note here. I started the acceptance script with 'go directly to the url..'. That's because at this early stage of the project I'm presuming there's no way to search or browse to that page. I didn't include price in this basic initial set of information. You might think that's fairly fundamental, but my guess would be that the price is stored in a more complex piece of the backend that we aren't talking to yet. I have included the cover image, assuming that is straightforward. These are all things I would know by talking to my developers. Adding the price would likely be my next story:



One temptation to avoid is putting dead links and buttons to things you haven't developed yet. It would be no work to add the button which says 'add to shopping basket' at this stage - but it wouldn't go anywhere. Doing this violates the principle of always having shippable software. Suppose we decide we have enough to beta the site as a kind of catalogue, without purchasing facilities - in that case we don't want buttons to non-existent ecommerce sequences to appear. That may seem pretty obvious - but it's quite easy to imagine buttons like 'Tell A Friend' or 'Add to Wish List' appearing on a live release before anyone remembers those features didn't make the cut. I'd add the button when I do the story 'Add book to Shopping Cart':



I think a lot of people might say here that I'm going too far, and these stories are too small. For a lot of situations they might be, I used to produce stories this size when working with teams whose iterations were only 1 week long. But I think the basic principle is sound. You can almost always break things down - If there's a tangible result and you can establish good acceptance criteria then it can be a story.

The Trouble With Release-Scale Estimation

With practice most agile teams get quite good at estimating individual stories, and hence at iteration planning.

However trying to extend the same ideas to the backlog and release planning often results in something like this...





Eventually (and possibly with the aid of a gun to their head) the team may come up with some numbers. Which then get used..



Project managers generally need release-scale estimates, and a lot of thought and effort has been expended in coming up with methods to provide them. Many, in the opinion of this author, are just a bunch of hocus pocus. Some work well enough within a team that understand their limitations and the assumptions that went into them. But when people start drawing charts and quoting story-point totals and 'burn rates' out of context then they're generally talking complete nonsense.

It remains a fundamental fact that you cannot accurately estimate requirements which aren't accurately specified - and if you are doing agile development and requirements are still in the form of vague epics on the backlog then they are not, by definition, accurately specified. If future requirements have to be worked out down to detail then you're no longer doing agile development - you're back in the waterfall world of the upfront specification with all the problems that implies.

So what's the answer? Really, the best answer is not to worry about it. If you prioritise properly, build the essentials first and aim for coherent on-time releases you perhaps don't need to bother with burn charts and all that jazz. Of course, some sort of estimation is still required, and there you can't beat experience and time-honoured tooth-sucking skills...

Product Manager vs Business Analyst

It's not often I read something on the Silicon Valley Product Group blog that I don't agree with, but as a former analyst by trade I wasn't too sure about this recent article on the roles of product manager versus business analyst.

The thrust of the argument seems to be that 'Business Analyst' is essentially a legacy role which overlaps with and confuses the responsibilties of the agile product owner. On reflection, I think that may be true - a good product owner who has time to focus on the development, engages with detail and undertstands technology probably doesn't need a business analyst.

And there's your problem right there. In my experience at least few product owners are able to fulfil those criteria. They're often appointed to a project from the existing 'business' side, sometimes with little prior technology knowledge. They may have wider responsibilties - departments to run, conferences to attend, 'offline' businesses to oversee. They may not even be co-located. In those situations a good analyst is invaluable, guiding the product owner through the maze of a technology project, being there every day to deal with the developers, focusing on details.

Similarly, developers should have the communication skills necessary to work with the business, but we know this isn't always the case, particularly in the age of outsourcing. The analyst's ability to 'speak both languages' is still very useful. Of course there are analysts and analysts - diligently beavering away on volumninous documentation isn't too relevant in agile development, the agile analyst needs to be a flexible and creative decision-maker.

As I said, a proper product owner as defined by the agile literature probably doesn't need an analyst. But in a world where most organizations can't simply reorganise to suit the ideal then there is still room for the role.

Story Acceptance Criteria: Say What You See

The real meat of a user story is in the acceptance criteria. A lot of the examples you see out there look a bit like this, taken from a Mike Cohn presentation:



In the situations where I have worked there's probably a bit too much going on there for one story, but in any event I wouldn't write the acceptance criteria that way. My version would look much more like a UAT script:



That's a much more detailed description of what the story should do. It's more effort to write, but for me when I'm writing the story is when I want to put the effort in, and when I have all the information in my head. Come the end of the iteration, I have a pile of stories waiting to be signed off and I don't want to spending time figuring out how to test 'verify cancellation' or whatever.

This type of 'do this - see that' script reminds me of the long-running British TV show Catchphrase, and host Roy Walker's constant exhortation to 'say what you see'.