I don’t know about you, but I always feel a little nervous when it comes to writing Agile stories. I often worry whether I’m the best person to write them and if I’ve got them right. The reason for the first worry is that the agile gospel says that the best stories are written by the customers whilst, the reason for the second worry is that my stories will be reviewed by a number of people including various project stake holders. All of which got me thinking: writing a story, how hard can it be? So, I took a good look around to see what advice others could offer.
Some of this advice was often vague such as that in James Shore and Shane Warden’s book The Art of Agile Development, which states that
“Stories represent self-contained, individual elements of the project. They tend to correspond to individual features and typically represent one or two days work”.
The book goes on to give other advice, such as stories “represent customer value” and should have “clear completion criteria”, which complies with the agile manifesto, but is all still pretty vague.
Now, I guess that some of this vagueness can be overcome by using the well known ‘as’, ‘I’ and ‘so’ convention for writing stories, which goes something like this:
Title: <some title> As a <role> I want <to obtain some goal> So that <I get some benefit>
Wikipedia puts the development of this idea down to the Connextra team who work for ad server people Connextra. The idea of this format is that it defines the story from a user’s perspective, it defines what the user wants to do and what the expected result should be.
But, I’m still worried. How much detail should I include in my story? What should be the scope of the work my story encompasses? Fortunately, James Shores comes to the rescue here. Remember that stories should also be used for estimation purposes and he says, in
The Art of Agile Development, that stories should take about 1 to 2 days to implement. I’ve got to find a short and concise form of words written from the user’s perspective with enough detail to provide one or two days work. Does this seem a little contradictory to you?
Then I had a revelation, it doesn’t really matter too much if your stories don’t contain enough detail, can’t be implemented or are just plain wrong. The whole point of stories is that they are a communication tool, they get talked about, reviewed, sized and estimated and that means that they’ll hopefully evolve. I guess that’s why agile generally defines two types of story: epic and ready.
An epic story is one that agilemodeling.com defines as a story that’s “too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories”.
A ready story is one that both a team can implement and a Product Owner can prioritise.
This, to me, seems an over simplification as between epic and ready stories there are often Fifty Shades of Grey, which is a different kind of story.
I thought that I’d try to demonstrate the evolution of a story by using an example and in the time honoured tradition of this blog, my example has to be far-fetched and contrived. In this example, I’m going to take the case of Backwater Bank inc, a good old traditional bank where your money is safe. They’re so traditional that they don’t have an Internet offering, they’ve got wooden counters, high ceilings, human tellers and cheque books; imagine the Building and Loan Company of Bedford Falls in It’s a Wonderful Life. But, this is the 21st century and their new CEO wants the bank to have a brand new website where customers can do everything they need to do without visiting their local branch. The new CEO hires Agile Cowboys inc to develop his website and Agile Cowboys inc’s CEO gets together with the bank’s CEO and come up with the following story:
As a banker I want my bank to give customers an online service So that I can compete with the big city banks and maximise my profit
This epic story defines the whole project; it’s totally unimplementable and if it were then it’s not very agile having just one story in your back log.
Agile Cowboys inc CEO figures out there’s a problem with this story and puts together an agile project team, passing the story on to the Product Owner before going out for a well deserved game of golf. The Product Owner has a meeting with the dev team and the some of the bank’s brightest staff (AKA the stakeholders) who start grooming the backlog of one story coming up with a whole bunch of stories including:
Title: Create a New Customer Account As a person in the street I want to create my online account So that I can become a customer of the bank
Title: Move Existing Customer Accounts Online As a banker I want to convert my customers' accounts into internet accounts So that they can access them on line
Title: Paying Bills As a customer I want to access my online account So that I can pay my bills
Title: Paying Bills As a customer I want to access my online account So that I can view my statements
Title: Account Transfers As a customer I want to access my online account So that I can transfer money between accounts
Title: Order Cheque Book As a customer I want to access my online account So that I can order a new cheque book
Title: Sales of New Products As the banker I want to sell the customer more products So that I can buy myself a new house in the country.
Title: Display Account Balance As a customer I want to access my online account So that I can see the balance of my account(s)
These are just a few of the online banking stories that spring to mind for Backwater Bank inc, but they’re still epics. How can you tell? Conventional wisdom says that you apply the INVEST mnemonic. Take for example the Display Account Balance story. It seems pretty straight forward coding wise: load a balance from the database and then display it on the screen; however, things aren’t that simple. It’s dependent upon either the Create a New Customer Account or Move Existing Customer Accounts Online stories, which must be completed before this one. Also, a whole bunch of questions spring to mind:
- What about security? How do we authenticate and authorise the customer to see their account balance?
- Are we coding for just one account balance, or is the customer going to be able to check the balance of any of their accounts?
- What about data access? Do we access Backwater Bank inc’s existing database or create a new one?
- What about server technology? Java? .Net?
- Do we have to support all browsers including IE6?
- What about today’s account transactions? Are they included in the balance as some cheques won’t have cleared?
Okay, so I’ve added a couple of implementation questions in to the mix, after all I’m a developer and I have to know what I’m dealing with before I can estimate things; however, getting back to the stories, these questions lead to the creation of new stories:
Title: User Logs In As the chief of internet security I want the customer to login and be authenticated against those things he/she is allowed to see So that the website is secure and a customer's data remains confidential.
It may also lead to the revision/splitting of an existing story. In this case, “So that I can get the balance of my account(s)” becomes “So that I can get the balance of my current account”:
Title: Display Account Balance As a customer I want to access my online account So that I can see the balance of my current account
…and another story for completion at a later date is added to the backlog:
Title: Display Balance of All Accounts As a customer I want to access my online account So that I can see the balance of all my accounts
Now, assuming that the Move Existing Customer Accounts Online story is complete, that you have chosen your server technology, setup your development environment, and have a fair understanding of Backwater Bank's database, can you implement the Display Account Balance story? Is it ready? Almost… We now need to consider acceptance criteria and for that we relate back to some of the earlier questions. For example:
Title: Display Account Balance As a customer I want to access my online account So that I can see the balance of my current account Acceptance Criteria 1) Will only need work using Chrome, behaviour on other browsers is undefined. 2) The balance will only consider transactions up to midnight of the previous day 3) Positive balances will be in black, for example $244.45 4) Overdrawn balances will be in red and use a '(nnn.nn)' format. For example:(134.87)
The final mark of the Display Account Balance being ready is an attached estimate and a priority in the backlog. This is done at the backlog refinement meeting (AKA product grooming meeting) attended by such notorieties as the Product Owner, stake holders,dev team and scrum master. In this meeting, if it’s priority is high enough it’ll get added to the next scrum and when that starts, the dev team will get busy.
And the end of the story? Well Agile Cowboys online project was a success and the bank’s customer’s used the internet to access their accounts. The bank’s staff didn’t have that much to do so, they spent their time lending money on the sub-prime market and paying themselves large bonuses. In 2008, the bank collapsed owing billions of dollars, only to be saved by you and me, the taxpayer.
As for me, maybe I should end by paraphrasing the Connextra Story Card:
Title: Writing Good Stories As a developer I want to know how to write good stories So that I can submit cards to the planning game that are clear and will be accepted in the next iteration.
Is this the start of another epic?
