Invest - what is a good Agile story part 2

Whilst wandering across the Agile landscape I came across an excellent mnemonic for getting a good set of story cards together; so lets INVEST in writing a good story:

Stories should be: Independent, Negotiable, Valuable, Estimable, Small, Testable:

• Independent - One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
• Negotiable - A user story is negotiable. The "Card" of the story is just a short description of the story which do not include details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.
• Valuable - Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realises that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.
• Estimable - The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
• Small - A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.
• Testable - A story needs to be testable for the "Confirmation" to take place. Remember, we do not develop what we cannot test. If you can't test it then you will never know when you are done. An example of non-testable story: "software should be easy to use".

I like this a lot.

Death by Technical Stories - what is a good Agile story card?

 

I have received and given training in what makes a "good" Agile story many times and seen many many more story cards that fill me with a sense of dread.

A good healthy Agile project needs people to not only understand what they need to implement, but also why and who for.  I know this has been written on the internet hundreds of times but it is worth writing again:

 

• So that...
• As..
• I need...

Now these are business headings (or Interaction Driven ones depending on what you read):

 

"So that" I can use a credit card online, "as" a web channel customer, "I need" a screen to enter my credit card details with"

Anyone picking up the story card can immediately see what it is all about, and if they turn it over they should get a set of acceptance criteria that define the "how":

"Must be able to input card name, long card number, expiry date, and csv number"

In writing cards from a user perspective it is easy to weigh up their necessity and business value as a part of backlog prioritisation and brokering, also as every card is effectively a placeholder for a conversation it gives detail as to who to go to talk to if things are not clear.

 

The worst stories that will quickly kill an agile project are technical ones, they should be forbidden:

• "So that I can index the database as a DBA I need..."
• "So that I can edit the codebase more effectively as a developer I need to install XYZ tool"
• "So that my class structure is better formed as a software engineer I need a book on Python"

  

As there is no way in seeing business value in technical stories then there is no way any product owner can "support" a story or indeed prioritise it over other features.  These cards should never be written and anyone who says they can't write a business story relating to a technical task needs asking, why are you doing the technical task then?

• Do - put something precise in each section that demonstrates the business value and pick a proper person or user group as the "As"
• Don't - write technical "So that”s or "I Need"s, or equally bad "a developer" "a user" or "a manager" etc in the "As"

Also, work with the product owners and BA’s to come up with a good “smart” set of acceptance criteria to go on the back of the card as these drive the whole TDD element of the Agile development process.

And finally for everyone who says you've got to put technical stuff somewhere; correct - it goes on the Task cards that underpin the stories, but these are only defined within the sprint Backlog, once the user stories have been selected to play in a sprint.

 

Happy story writing!

Who gets involved in what during the Agile cycle

Well the short answer is that in a highly colaborative environment everyone gets involved where they can add something to the discussion (not just prolong a discussion with anecdotes and trivia though)

Following a conversation I was having with a colleague (a very pragmatic agile manager) the other day I produced the following picture which neatly describes the "layers of the cake" and who gets involved.  Solid lines are primary involvement and dotted lines are more informal, informing or secondary.

I think its pretty self explanatory, cognisant there will always be times when people across the spectrum get involved in odd tasks, I was however very pleased with the form and simplicity of it - so thank you Matt Taylor and I hope you don't mind my choice of colours.