How Detailed Should Tasks Be in a User Story?
This is a guest blog post by Joe Woods from VersionOne... When I first started using agile project management, my stories didn’t have enough detail. In my office we use Agile to manage our marketing department with 2 week iterations. Even from the beginning, I could see the value of bite size goals that you could accomplish in a short time span. Agile project management is effective in managing...
Independent Interpretation
Many organizations segregate their programmers and testers in order to achieve independent validation of requirements. If the system is tested according to an independent interpretation of the requirements than used for implementation, then errors in those interpretations...
A Sample Format for a Spreadsheet-Based Product Backlog
I want to show a real easy way to put user stories in a spreadsheet-based product backlog. I wrote this after seeing someone tweet a screen capture of a product backlog I made 9 years ago and thought to myself, “Yikes, that’s out of date for how I do it today…” As...
Agile User Stories, Themes, Epics, Features – What’s The Difference?
A recent comment on one of my blog posts asked about the difference between agile user stories, themes, epics, and features, and about the relationship, or hierarchy, between these terms? Admittedly it is a bit confusing, as these phrases are often used quite...
Themes in Agile Software Development
Agile software development teams often use User Stories as a simple and concise way to express user requirements. Ideally these User Stories are broken down as small as possible, whilst also trying to minimise dependencies. Naturally, though, as you break User...
User Stories versus Use Cases
Scott Sehlhorst from Tyner Blain is one of my favourite bloggers. He's written an excellent post about User Stories versus Use Cases. When I first used Use Cases, I loved them... I loved the fact they gave such a clear description of a feature, and the fact...
Burndown User Stories, Rather Than Tasks
I was very interested to read this blog post from Ron Jeffries about burning down user stories rather than tasks. Excuse the pun, but this is a hot topic for me at the moment :-) If it's possible to avoid the time spent in Sprint Planning, breaking user stories...
Role Storm
Joe Ocampo ('AgileJoe') has recently written about a concept he calls 'Role Storming'... I'm not sure I like the name - sounds a bit buzzwordy - but I think the concept is really great! When you first start a project, you need to build out the initial Product...
Putting the *Analyst* into Test Analyst
For years, I've given Software Testers in my teams the official job title of Test Analyst, or something along those lines. Yet (informally) I've always referred to them as Testers. Only in more recent years - and especially since adopting Agile Software Development...
Writing Good User Stories
Over the last few weeks, I've written alot about writing good User Stories - you can see them all here: User Stories. User Stories are a simple way of capturing user requirements throughout a project - an alternative to writing lengthy requirements specifications...
User Stories Should Be *Testable*
The *T* in the the 'Invest' acronym (a way to remember and assess what makes a good User Story) stands for Testable. The most common forms of User Story that are not testable are big User Stories, known as Epics, or non-functional User Stories... An Epic can...
User Stories Should Be *Small*
User Stories should be small. This is what the *S* stands for in the the 'Invest' acronym; a way to remember and assess what makes a good User Story. Not too small. But certainly not too big. So what is the right size for a good User Story? First of all, let's...
User Stories Should Be *Estimatable*
User Stories should be possible to Estimate. If you follow the other aspects of the 'Invest' acronym, chances are they will be. The *E* in 'Invest' stands for Estimatable; another useful way to measure whether a User Story is good or not. So what are the potential...
