Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Thursday, January 26, 2006

Writing Good User Stories

One question I get asked a lot when discussing agile project management is this:

How do I write a good user story?

I talked about Mike Cohn's book on this blog previously, and it is an excellent source of information.

However, for those of you who don't have time to read a book, I'll offer a few of my own tips:

1. Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn't practical, then you'll have to role-play. An example of a developer-focused story is "Add clustered index to the Orders table." This doesn't mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like "Improve Order reporting performance", captures the same information, but is understandable to everyone on the team.

2. Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don't write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.

3. Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren't usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.

4. Make them testable. An untestable story might be something like "Make the order screen easy to use." It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: "A novice user be able to load, enter information, and submit an order within 5 minutes." Hmmm...still seems a little questionable, but I can probably write a test like "Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes."

This is just scratching the surface of the topic, but I hope these tips give you a little direction when starting to write stories.

For more agile tools and tips:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Monday, January 23, 2006

Book Review - User Stories Applied

I recently finished Mike Cohn's book User Stories Applied, an excellent and well-organized guide to agile software planning, development, and testing with user stories.

The book starts with the basics of what a user story is and is not. For example, Cohn points out that stories are not IEEE requirements ("The system shall support donut making") or use cases. They are reminders of future conversations between customer and developer.

The book continues with comprehensive coverage of how to write good stories at an appropriate level of detail. It discusses strategies for how to tell if a story is too big, too detailed, or too vague, and how to fix those issues.

What separates this book from other Agile writings is the breadth and depth of examples. Cohn has an entire section of the book to work through a detailed example of analysis, release planning, iteration planning, acceptance test writing and more. This is the most complete discussion I've seen on the topic of acceptance tests, what they are, and how to write them.

As an extra bonus, Cohn has chapters on using Scrum (a popular agile project management technique) with user stories that includes a good overview of the process itself. Another chapter summarizes Extreme Programming practices.

Each chapter has a summary of the most important topics covered, as well as the responsibilities discussed for each role (Customer, Developer). You could actually just skim the summary at the end of each chapter and still come away with valuable information.

There are also reader exercises at the end of each chapter (but don't worry, the answers are at the back of the book).

Overall, in my opinion, this is the most practical, no-nonsense guide to working with user stories and Agile methods available. This would be an excellent book to use with a training course, or just to have the whole team read before starting a project.

For more on agile tools and techniques:

(Tags: , , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Friday, January 20, 2006

Goal Driven User Interface Design

Can an agile development team build a usable, non-trivial user interface in 2 weeks? Or do complex user interfaces and interactions require some upfront design to get right?

User interfaces defy the "just build it and get feedback" approach in that once they are deployed and learned, major changes can be very disruptive to end users. Assuming for a minute that the customer doesn't have expert UI designers on staff, and is expecting you to provide a reasonably effective UI, how do you proceed?

Some options to consider:
  • Stagger the design and implementation cycles so that the team analyzes the user's goals and does sketches and mockups of the UI in Iteration 1, to be coded in Iteration 2. This probably requires at least one person dedicated to this role.
  • Perform upfront analysis that tries to capture user roles, agendas, and goals before any development begins. Interaction design advocates this approach, and its supporters say that this initial analysis does not change much over time, and so is worth doing early.
I believe that understanding user goals is critical, and a great time saver before the major coding begins on a project. This doesn't have to be a huge effort that takes months of field study, but it probably does mean talking to users of the software in their various roles. It might take anywhere from a few days to a few weeks depending on any travel that's necessary, and on how many user roles you're exploring. But again, even a little bit of goal analysis is better than nothing.

A common objection to this sort of early analysis is something like "But I have an onsite customer, I'll just ask her when I run into something." This can be very effective for domain-specific questions, but less so for something outside of the onsite customer's direct experience. If your system has a function that only shipping clerks will use, asking the inventory manager what the screens should look like may not be the best way to go.

If you absolutely can't get access to real users, you can use "personas" or user role analysis to figure out what they *might* need. This isn't ideal, but it's a lot better than nothing.

The process might look something like this:
  1. Brainstorm all the possible users (real people) of a system. For a sales management system, that might be: Salesperson, Regional Sales Manager, VP of Sales, CEO, CFO, and probably most importantly, Sales Assistant.
  2. For each role, try to identify the goals they have in their job, and how the system might support those. The Sales Assistant may have a goal of keeping her 4 Salespeople happy. This might translate into being able to access their information quickly, switching between customers for different salespeople, etc.
  3. From the goals, you can start designing possible UIs to support them using paper, whiteboards, or drawing software.
  4. Test the prototype drawings against the user goals and scenarios to validate them.
  5. Start developing software based on the validated prototypes.
In my experience, you can definitely build software without going through any of this (and I have). But time and time again, the most customer-satisfying user interfaces I've developed have come from doing some initial goal analysis.

As a strong proponent and longtime practitioner of agile methods, I don't much like the idea of spending a lot of time on upfront analysis. But goal analysis, especially when the user interface is sensitive (repetitive use applications, those that need to be very easy to learn, etc.) can be time well spent.

For more on agile tools and techniques:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Monday, January 09, 2006

Agile Practices Considered Harmful?

In some recent agile newsgroup exchanges I've read, it appears that there is a split in the agile community between what I'll call Rule Followers and Rule Derivers, or just Followers and Derivers for short.

The Follower mantra can be stated as "If I follow all the rules and best practices that I read and hear about, I will be optimally Agile." Taken to the extreme, this mindset implies that there is One True Path(TM) to agility - follow the rules, and you'll get there.

The Deriver says something more like "Given a set of desirable properties for this project, I'll experiment with some possible practices to see how they help us reach those properties." This is more in keeping with agile principles, which are about rapid feedback, inspection, and adaptation. Do the simplest set of things that could work, check to see if it is working, and if not, tweak something.

The main problem with a literal interpretation and application of practices is that if any one of them fails or is unpopular, a Follower has no recourse. It's an all or nothing proposition. In fact, the original XP book (XP Explained) suggested that if you weren't following all of the specific practices, you weren't "doing XP." I think that this is where much of the controversy around XP stemmed from - a seeming lack of flexibility with respect to the practices. In reality this position seemed to be more about protecting XP from bad publicity due to flawed implementations than any resistance to adaptation from the author.

On the Deriver side of the world, the main concern is "reinventing the wheel" in an effort to customize a set of workable practices. It would certainly be easier to take a package of practices, try them all, and only adjust when some aren't working well. What seems to happen in practice is that teams pick and choose the practices they're comfortable with up front. A true Deriver constantly measures and adjusts based on those measurements.

Either approach is a valid way for teams just starting with agile techniques to try, but in the long run, adaptation has a brighter future. Having a clear set of principles, not just practices, can help a team get closer to the Agile ideal - better software, happy customers, and happy developers.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams