If you follow this blog we'd prefer you to use the new address - http://blog.energizedwork.com. However, we'll continue to support http://www.agileinaction.com (and http://www.think-box.co.uk/blog) until further notice.
Links to this post
Backstage at Boffoonery
Finally
Boffoonery happened last night and it was absolutely spiffing fun. I'm so glad we sponsored it. It was a triumph and a wonderful tribute to
Bletchley Park and to those who worked there. Congratulations to the cast, especially
Johnny Ball for his performance during the quiz and for reminding me of the fun I had as a child watching his TV shows.
Jason, you can be proud of what you've done here and you thoroughly deserve that big cigar!
Clive Flint was a superstar and came to the rescue at the last minute to take some
wicked photos on the night. It was cool to go backstage beforehand and impose as the stars chilled out. And it was great to talk with
Simon Greenish at the bar afterwards. Thank you again for your invitation to Bletchley Park. We'll be up there pronto.
Thanks Jason for the
Commutineer coverage especially the centre-spread in the programme (below). We're continuing to improve
the Web site and we'll continue to do so beyond the official launch later this month. So don't wait until then! If you're dallying with the daily commute please share your experiences, observations, encounters at
commutineer.com. Be naughty. Or nice. What you say may be useful to other commuters. And we'd love more feedback. We plan to hook it up to Twitter too. So if you're tweeting about your commute please tag it #commutineer.
Labels: boffoonery, commutineer
Links to this post
How we use stories
All our work items, both user-focused and technical, are stories framed in the context of a user interacting with the product. Each story represents a distinct, visible and testable piece of work that can be delivered independently to realize some value. Stories exist at many levels of specificity and never convey solutions. For example, at a point in time it's sufficient to use an ambiguous story to describe an interaction as simply an activity a user engages in using the product. At some time later, typically when detail starts to matter, smaller stories are written to describe that activity in terms of more specific tasks the user performs with the product.
Stories are written on index cards measuring 6 by 4 inches. A description of the user interaction is written in as few words as possible on the front of a card to provide a brief outline. This provokes conversations to reveal and understand the details, which are captured as acceptance criteria on the reverse side in the language of the user. The physical card serves as a token, exchanged amongst the team when different people work on the story. It also acts as a physical flag that shows others what's in progress and a story's history in terms of the feedback obtained so far from testing, user experience, etc. Different colored index cards are used for different types of user:
1. Business and end users
- White cards describe stories written for business and end users.
- Green cards describe user experience stories that need to be completed ahead of time and in just enough detail, e.g. using low fidelity prototypes or design mock-ups, to facilitate an iterative approach and provide useful input to the corresponding white cards.
- Pink cards describe defects from the users' perspective and include the steps to reproduce on the back. We never debate whether something is a defect or not, we just ask the product owner.
2. System and technical users
- Yellow cards describe stories written for technical users, e.g. a system administrator operating and supporting the product, or for discrete system engineering work such as scalability and resilience.
3. Technical debt
- Blue cards describe stories written for developers, who are considered users of the system at an engineering level. They describe technical debt in system and software terms and include acceptance criteria on the back so the developers know when they're done.
The size of a story isn't important until it's planned and prepared, ready to be implemented.
Developing the product iteratively
Using iterative development we progressively refine and extend functionality already delivered. Over time a user task is sometimes revisited by any number of stories. Whenever possible we use a green card to build a paper prototype that allows us to evaluate interaction designs with users before developing any software. The first white card typically delivers very basic functionality that allows users to perform the task using the product. Feedback from users validates our assumptions and often initiates a new story to enhance the functionality or improve its performance and ease of use. Every story aims to improve the experience for the user based on their feedback to enable them to perform the task more efficiently or effectively.
By delivering a minimal version of functionality early and then evolving it in response to user feedback, we remain receptive to discovery and keep our options open rather than committing prematurely to a specific user experience. This way we invest more wisely to deliver exactly what the users wants, and no more.
Labels: defects, real options, technical debt, user stories
Links to this post
