Tips for Effective User Story Gathering Meetings
The typical approach in gathering requirements for an agile managed software or hardware development project is to first conduct user role modeling meetings. A collection of developers, product people, marketing, subject matter experts meet to brainstorm all the different user roles that will interact with the system being created.
After gathering the list, the next step is to generate a list of user stories. One very effective way to do this is to conduct user story gathering sessions, where the group of project members and customers iterate through each user role, brainstorming all the ways the user will interact with the system. Often, a paper prototype outlining a rough workflow is used or created during the session to facilitate the conversation.
Mike Cohn has done an excellent job describing both of these activities in his books Agile Estimating and Planning and User Stories Applied. I’d like to suggest a few tips that have helped make these activities even more useful in generating requirements documentation
- Prepare paper prototypes before the user story gathering meetings with the obvious stories. This will give your meeting attendees a good starting point, serve as examples of how to do a prototype, and speed things along.
- Use Visio or Powerpoint to build your paper prototypes instead of a whiteboard or notecards. Having an electronic copy I can pass around to distributed members of the team is very useful. Plus I find that I am often flipping between multiple workflows during user story gathering meetings, which is hard to do if you drew everything on a whiteboard that might be already erased.
- Start with the user role with the largest role in the system and work your way through each user role in descending order of system interaction. This will cause you to write up a lot of different paper prototype workflows. As you get further down the list of roles, you will find that the paper prototypes you need to facilitate the discussion are mostly already built. (Yet another reason to keep your workflows in an electronic format)
- Don’t forget to gather stories for the hidden users roles! I find it extremely useful to work through the system as the role of developer, designer, project manager, qa manager, product owner, suppler, etc. Example stories you could generate as a project manager for a new web application project could be:
- As a project manager I want to conduct a PCI compliance gap analysis for my planed network architecture to make it easier to attain compliance later.
- As a developer, I want to setup a continuous integration server for the project so that our unit tests are executed regularly.
I hope you find these suggestions useful.
Don’t Mix Brainstorming and Estimating Effort in the same Design Meeting
Recently, Derrek Long, my system architect, asked me to read a few pages from the book I.M. Wright’s Hard Code by Eric Brechner. He had observed issues our company was having with mixing brainstorming and scope cutting in the same meeting. Brechner describes over a few page in Chapter 5 how to avoid getting FOCKED, or “Failing to Orchestrate Collective Knowledge Effictively for Design”. Essentially, Brechnar preaches to have very specific goals for a meeting, and to avoid at all costs mixing goals, especially when the goals are completely opposite to each other.
After reading Brechner, and thinking about it for the last few weeks, I’ve expanded this idea out a bit further as to why mixing brainstorming and estimating effort during initial design meetings between the business stakeholders and development is a bad idea.
- Discussing effort for each idea discourages creativity when brainstorming. People will be less likely to offer “out of the box” or “half baked ideas” that need to be flushed out if they are afraid they will be scolded for coming up with something “too hard”.
- Dev often will give a big estimate when they don’t like an idea. So waiting to estimate the idea at a later time demonstrates that dev still put in the due dillagence to consider the idea and the estimate isn’t just based on dev not immediately liking it.
- Initial estimates given 10 seconds after hearing an idea in a brainstorming meeting will be less accurate. Dev needs time to absorb the idea, think it through, and then offer an estimate of effort. Even spending 5 or 10 minutes considering an idea results in the developer spending 100 times more time considering the idea and will result in a more accurate and reliable estimate.
- Other ideas presented later in the meeting might add further clarity to earlier ideas or might prevent the idea from needing estimation altogether.
I would love to hear from other people their experience with keeping brainstorming and estimating separate. If you have techniques you employ to do this, let us know!
Save Time… Avoid Agile Planning Poker
The agile project management technique of planning poker is a popular estimation process for software development. My favorite Agile author Mike Cohn presents a good description of the practice on his blog here: http://blog.mountaingoatsoftware.com/?p=14.
Let me start off by saying that I really like planning poker. It’s a very clever way to estimate user stories. However, from a tech startup standpoint, where time is a critical resource, planning poker becomes a non-essential part of the agile process. Here’s why:
- The cost is material. My typical 2 to 3 week iteration has approximately 40 stories. I find that it takes between 2 to 5 minutes per story. Using 3 minutes as average, that brings us to 120 minutes. So my team of 10 people, spend 2 hours in planning poker. Multiply that by $75/hour and you get a cost of $1,500, not to mention the opportunity cost of not coding. At a startup, where time is so valuable, this is a tough pill to swallow.
- After several iterations and planning poker sessions, I began to realize that I could estimate just as good as the developers. I would compare actual hours reported by my developers spent on user stories to the story points estimated and calculated that my estimates had the same standard deviation as the whole team did the estimation. Even if you continue to practice planning poker, this is an excellent exercise to refine your estimating skills.
- Take shortcuts. The average bug tracked in our bug tracking software is about a 1 story point. Skip estimating every bug and just apply this average.
- If deadlines are less critical to your particular situation, then why care so much about your estimates? My web application dev team often has a release plan that changes every couple weeks. We are not tracking a burn down to know when the release is complete, because the story make-up of the release changes so frequently. The burn down chart is not actionable for us.
On particularly large stories or Epic’s, I ask the developer who will probably be working on the story to give me their estimate. But for the majority of user stories, I take care of the estimation. Maybe you can too?
About
A blog about software development, marketing and general business practices at an Internet Startup.
Keith is currently a co-founder and Director of Product Development at RideCharge, a startup mobile and web taxi booking service. Prior to RideCharge, Keith has been an IT project manager, Java developer, and PeopleSoft developer. He holds a MS in E-Commerce Technolgy from DePaul University.
