Time for the second morning session here at CodeMash. This session is called User Stories Closing the Agile Loop and is being given by a gentleman by the name of Barry Hawkins.
Barry says requirements churn is not a crisis. This really hits home, it feels like it is, but it is also a reality. Barry is now walking through the agile manifesto. Creating working software over comprehensive documentation does not mean we don’t create any documentation. It means we create high quality documentation that people actually want and use.
Barry’s reviewing the pieces of the manifesto and talking about his real world experiences and what they practically mean to him. This is really interesting stuff. Comparing estimation process with business in its usual way similar to a game of poker. Points out contracts are made at beginning of project when we are as ignorant as we’ll ever be about the project, this may not be the optimal time to lock in absolutes. An Agile approach would dictate a softer approach that involves collaborating and allowing for changes along the way as we learn more.
Underlying agile assumptions: Motivated self-directed people make up the team. Cross functional team, have everyone you need to move product from concept to launch. Good teams have a QA person at all stages, not just at the end. Teams have highly available domain experts. A culture of testing. A failure tolerant environment. Value projects completed, not projects launched (context switching for developers can be time costly).
Most agile adoption is driven by development teams. Usually it is not management that proposes development is done using an agile methodology. This produces situation where development doing iterative approach while business is still providing phased waterfall analysis, use cases at best. Hard to fit non iterative requirements/analysis process into iterative development process, very time costly to translate requirements.
What are user stories? Barry recommends the book User Stories Applied for deeper understanding. User Stories are place holders for interaction, not a substitute. User Stories are much smaller than use cases, they focus on a small strip of functionality, they don’t dictate detailed requirements such as UI requirements. User Story structure: “As a ___ user, I can ____, so that _______”. Structure defines who is going to do what and what benefit it will provide. The “so that’ is the benefit statement and is very important. Stories should follow Bill Wake‘s INVEST acronym: Independent, Negotiable, Valuable, Estimatable, Small, and Testable.
But what about __________. Business won’t cooperate: maybe business doesn’t like you, you say no to often. Could it be that business has come to believe no will already be the answer. Functional spec already written: you can turn these into user stories. Team is not co-located: wiki’s can help here. no UI for code : just becuase no UI doesn’t mean there aren’t users.
Well that’s that. Very good presentation I thought.