Use Physical Story Cards

Sometimes you want to use an electronic Agile Application Life Cycle Management (ALM) tool for managing your user stories. There are benefits to using a tool. They have some really nice features, some of which can't be done in the physical realm. And sometimes you've just got to go electronic; you have no choice. But even if you've gone virtual, there are still benefits for having physical cards as well.

I like having my user stories on physical cards. Conversations are richer, and shorter, when you can point and ask "What's the difference between these two stories?" and the answer is "THIS story is about… but THAT story is for…".

Planning poker is great, but the Team Estimation approach is often better, especially if you have a dozen stories or more. I love it when someone can tell the team "I think THIS story is smaller than THAT one and larger than THIS one" and everyone immediately understand which stories he's talking about.

Relative prioritization is easier when you can slide around some physical cards, especially if you need to prioritize collaboratively. "I'm okay with what we've laid out here, but if you think THAT story is THAT high a priority, you are nuts!"

I recommend having a pre-planning meeting to help make iteration planning will go well. That first pre-planning before a team's first iteration planning meeting is particularly difficult. You don't know what your velocity is. You don't know how much you can get done. You may be unsure of dependencies. All this agile stuff is new. And you need to get several people to feel confident that the 1st sprint planning will go well. You have this large backlog of stories and you want to be sure everyone understands what we're sure we're putting in, what we're considering to put in, and what we're not putting in. So lay it out on the table. I love being able to slide cards around on a table and to be able to literally put something aside for now if it's giving us grief. It's not off the table, it's not out of sight, it doesn't look like it's still in the list, but it won't be forgotten. "Let's come back to THIS one later."

Story mapping just has to be physical until we get inexpensive wall-size touch-screen monitors and story mapping software.

I've worked with clients that were very happy with their ALM tool and large monitors. I was impressed with their dedication to making agile work, their open space, and these monitors for each team. But as big as the monitors were, it still just seemed easier to me to manipulate and read fat sharpie on index card. And I can write SPLIT on a card faster than I can tag it as too big in an ALM tool.

Sketches are interesting. A picture is worth a thousand words. Would be harder to do this on anything other than paper.

But using an ALM tool doesn't mean you can't have physical cards too. It's pretty easy to write the story title and estimate on an index card. You can write the story's ID number from the ALM tool on the card. You can also print story cards from some of the tools. VersionOne has always had a printing solution, but the version coming out in August 2012 will have the ability to print directly from the tool.

I've heard of other tools that make it easy to print, but I can't name them off hand. If you'd like to mention your tool in the comments, please do.

Lots could be written about keeping physical cards and an ALM tool in sync. I'm going to ignore keeping a Scrum card wall in sync in order to keep this post on the short-side, but I will add the following. If you are using physical cards for a prioritization or sizing exercise then just enter the updates back into the ALM tool and discard the cards -- or hang on to them for some other purpose if you want. The point is, the cards served their purpose, they are transient, update the tool and you are done. I could also approve of doing a story map at the start of a small release, then leave it on the wall as is as a historical vision document while the ALM tool becomes the plan of record. I also recommend sticking with physical cards through Iteration Zero and Iteration One. What's cool in I0 and I1 is using the same cards for socializing, estimating, prioritization, pre-planning, and finally planning and the daily standup, then seeing a gold star put on that sucker once it's done.

Bottom line: Keep using physical cards. I promise it will be worth it.

Consider Stories at Multiple Levels

I often work with teams adding new large features to existing applications. It is common for teams like this who are new to agile to go into too much detail too soon. It seems that those accustomed to waterfall believe you've only got one shot to discuss any requirement, so they must discuss it in detail.

In agile you get many looks at each user story (requirement), preferably from many different angles and ultimately getting progressively more detailed as you go. I like to explain it with these four levels.

VISUALIZE -- The Concept

We typically start with a project name or enhancement name, don't we? It's the handle by which we call this thing. From there we hope to have the vision, a short narrative for what we're after. Perhaps we have the name of a few super-epics. Refine that into some epics. Begin to understand the minimal marketable features (MMFs). Metaphorically, this may be an aerial view of the forest, or maybe the planet. Keep the vision in front of the team throughout the project.

PRIORITIZE, ORGANIZE and SOCIALIZE -- The Forest

By prioritize and organize, I mean use any approach to help the team see how the stories fit into the vision and understand the minimal marketable feature set. An example technique is Story Mapping. Understand your epics. Metaphorically, this is understanding what the forest full of trees looks like.

None of these are a one shot deal. Iteratively refine your prioritization. Tune the MMF and re-socialize stories as you learn and get feedback. You aren't done socializing just because sprint zero is over. For anything of size, you don't get done socializing in just one meeting. Nor does all the socializing happen in meetings.

SIZE -- The Trees

When sizing (with abstract relative points), look at your stories in a little more depth, but not to the level of detail described below. Look at it just enough to give an estimate relative to the other stories. You don't need as much detail for a relative estimate as you would for an hours/days/weeks estimate. You quickly get to a point of diminishing returns. Consider that we use a Fibonacci series or something similar -- we use a diminishing level of precision as the stories get larger. Once you are pretty confident that it's a 21 point story, you don't need to spend more time to make sure it isn't really a 13 pointer.

As with the above, you may look at a story for sizing multiple times. If you've sized a bunch of stories at the start of a release, you should re-size the remaining work after 3 to 5 iterations. By then you've learned more. You will have become more familiar with the project, subject matter and the affected code.

Sizing also shouldn't be expected to be static. How big a 3 point story is will shift over time, especially but not only because of changes in the team. Hopefully the individuals are getting better, smarter, and the code is getting cleaner. Also, the work that we're comparing stories to changes. Point-drift happens. Old estimates are like milk -- they don't get better with time.

PLAN -- The Details

In iteration planning we break stories down into tasks. We estimate tasks in hours or half-days or maybe in pomodoros. We think in terms of detailed design and code and test cases.


Understanding that we're going to see each story multiple times with progressive levels of detail helps overcome the desire to go too deep too soon.

What approaches have you used to help people think about stories at the appropriate level?