INVEST in User Stories

When looking at the goodness of a User Story, see if you should INVEST in it

Independent – each story should stand on its own

Negotiable – stories are in invitation to a conversation; there must be flexibility and room for change. The bigger the story the more details need to be negotiated

Valuable – the story must provide business value; that is its only reason for existing

Estimable – to be useful a story we must be able to estimate it; estimation and tracking are core aspects of an agile process

Small – at most a couple of staff-weeks of work. Too big -> too hard to stay to know what the story is really about.

Testable – if a story is not testable we will not be able to determine if it done; a story is complete once it has passed all its tests.

Running Tested Features

I found a very insightful article on an agile metric at http://xprogramming.com/xpmag/jatRtsMetric  by Ron Jeffries called A Metric Leading to Agility. The metric is Running Test Features (RTF)

My take aways:

1. RTF causes the team to focus on features -> feature counts are measured and should grow every day.
2. RTF forces tests to be automated
3. RFT promotes design for testing and because the RTF curve is expected to grow smoothly it encourages a clean design
4. Monitoring the RTF curve can be an early (instant) indication of a problem -> solving the problem involves talking to the team.

We are just starting to use an agile methodology and I am finding out as much as I can to make it successful. I will be very interested in how useful we find this metric.

User Story Nuggets

Format: I as a (role) want (function) so that (business value).

The main purpose of a User Story is to be a reminder to have a conversation.

A good way to get the initial User Stories is to consider the goals that each user has for using the software.

To avoid blending solutions with requirements strive to specify the UI as late as possible.

http://www.agile-software-development.com/2008/01/example-of-user-story.html

The Conversation section provides more information about the story – the invitation for a conversation.

The Confirmation section provides the test cases for the story- how the story will be confirmed.

Both the Conversation and the Confirmation represent the requirements for the story.

User Stories are written to facilitate release and iteration planning as well as an invitation for a conversation.

While Use Cases are written as a result of analysis, User Stories are written to initiate an analysis conversation.

Agile Architecture

I love this quote from http://techdistrict.kirkk.com/2009/09/11/agile-architecture-presentation/

The goal of architecture is to minimize the impact and cost of change. To do this requires we create flexible systems with the ability to adapt and evolve. But with flexibility comes complexity, presenting architects with a paradox. As we design more adaptable systems, the additional complexity reduces their ability to survive. Eventually, the software rots, the architecture crumbles, and the system fails. Therefore, we must find a way to increase adaptability without decreasing survivability.