Thanks to Joserra Díaz for the translation (with feedback from Matin Alaimo and Alan Cyment).

This poster is also available in English, French, German, and Russian. You’re welcome to print copies for personal use.

For more information, see the original story splitting patterns post.

Thanks to Alexander Lutsaevsky for the translation.

This poster is also available in English, French, German, and Spanish. You’re welcome to print copies for personal use.

For more information, see the original story splitting patterns post.

Thanks to Jean-Jacques Lévesque, my “How to Split a User Story” poster is now available in French.

Click the thumbnail below to get the PDF.

This poster is also available in English, German,Russian, and Spanish. You’re welcome to print copies for personal use.

For more information, see the original story splitting patterns post.

As an organization transforms to an agile way of working, functional managers (e.g. a dev manager or a test manager) can feel lost. Many of their traditional responsibilities move to other roles or disappear altogether.

How can functional managers continue to add value in an agile organization? Here are a few ideas…

1. Build a community of practice for the function across multiple agile teams. This allows lessons learned by the testers on one team to spread to testers on the others. It makes it more natural for developers on one team to seek help from developers on another.
2. Provide training and other skill development opportunities and resources across teams.
3. Take a strategic view on the function. Look across multiple teams’ product road maps and evaluate how well the current skills and knowledge match future needs. Take steps to fix any gaps (i.e. through training, hiring, etc.).
4. Help team members, HR, etc. align functional, team, and organizational measurements, goals, etc. For example, agile teams often see the best results when team members are willing to work across specialties as needed. But traditional metrics and goals might penalize a developer for helping with testing. Functional managers can help break down these disincentives to collaboration.
5. Continue to take care of personnel responsibilities such as performance reviews, hiring, and firing. However, because functional managers are likely to have less direct, day-to-day interaction with employees, they need more input from Scrum team members to do these than they might have in the past.

Are you a functional manager in an agile organization? How has your role changed? How do you add value now? Share in the comments.

Thanks to translation from Kai Simons, my “How to Split a User Story” flowchart is now available in German.

Click the thumbnail below to download the full-size PDF version.

This poster is also available in English, French, Russian, and Spanish. You’re welcome to print copies for personal use.

For more information, see the original story splitting patterns post.

More than two years after I originally published it, “Patterns for Splitting User Stories” remains one of the most visited posts on my blog. Splitting user stories continues to be one of the areas where the teams I work with most often need coaching.

To support the teams I coach, I’ve created a flow chart that goes through the questions I’ll ask when I’m helping a team split their stories. I was going to keep this resource for my coaching clients, but I’ve decided to share it here for free. Click the thumbnail below to download the full-size PDF version.

Let me know in the comments if you find this useful. If you can share them, I’d love to see examples of how you’ve used it, what the stories looked like before and after splitting. You’re welcome to print copies for personal use.

Update: This poster is now also available in German, French, Russian, and Spanish.

Atul Gawande is a surgeon and author who has written some excellent books and New Yorker articles reflecting on the state of modern medicine. Recently, his writing has gone beyond medicine in interesting ways. As he looks for lessons for medicine from other disciplines, he ends up with things to teach both medical professionals and skilled knowledge workers more generally. His book The Checklist Manifesto manages to be a riveting 224 pages on what ought to be one of the least interesting topics possible: the checklist.

So I was intrigued to see a link to a New Yorker article from Dr. Gawande on my own specialty, coaching. It’s as good as I might have hoped. Noticing that his own performance as a surgeon seems to have plateaued, he wonders whether a brief experience with a tennis coach might apply to surgery:

One July day a couple of years ago, when I was at a medical meeting in Nantucket, I had an afternoon free and went looking for someone to hit with. I found a local tennis club and asked if there was anyone who wanted to play. There wasn’t. I saw that there was a ball machine, and I asked the club pro if I could use it to practice ground strokes. He told me that it was for members only. But I could pay for a lesson and hit with him.

He was in his early twenties, a recent graduate who’d played on his college team. We hit back and forth for a while. He went easy on me at first, and then started running me around. I served a few points, and the tennis coach in him came out. You know, he said, you could get more power from your serve.

I was dubious. My serve had always been the best part of my game. But I listened. He had me pay attention to my feet as I served, and I gradually recognized that my legs weren’t really underneath me when I swung my racquet up into the air. My right leg dragged a few inches behind my body, reducing my power. With a few minutes of tinkering, he’d added at least ten miles an hour to my serve. I was serving harder than I ever had in my life.

Not long afterward, I watched Rafael Nadal play a tournament match on the Tennis Channel. The camera flashed to his coach, and the obvious struck me as interesting: even Rafael Nadal has a coach. Nearly every élite tennis player in the world does. Professional athletes use coaches to make sure they are as good as they can be.

But doctors don’t. I’d paid to have a kid just out of college look at my serve. So why did I find it inconceivable to pay someone to come into my operating room and coach me on my surgical technique?

The rest of the article wanders through a history of coaching; interesting examples from sports, music, and education; and describes his own experience engaging a coach. He concludes,

There was a moment in sports when employing a coach was unimaginable—and then came a time when not doing so was unimaginable. We care about results in sports, and if we care half as much about results in schools and in hospitals we may reach the same conclusion.

I value coaching enough to spend my own money on it. I’ve hired a mountain bike coach, Lee McCormack, to help me prepare for this summer’s Trestle All Mountain Enduro race. It’ll be my first downhill race. I don’t expect to win, but I want to get a result I can be happy about and enjoy the experience.

I used to do cross-country mountain bike races, and I have a pretty good idea how to train for an event. I have Lee’s books. I could probably do this on my own. But I know from my own experience as a software development coach how much faster a good coach can help you improve.

Lee McCormack on his backyard pump track

After just two hours of coaching—working on things I would have said I already knew how to do—I could see a marked improvement in my skills. And I had a nice list of things to practice on my own.

This brings me back around to software development. Our world today runs on software. But most software teams struggle to deliver anywhere near as quickly and reliably as they could. A software profession living up to its potential would transform the world. So, to paraphrase Gawande: If we care half as much about results in software development as we do in sports, how is it imaginable that so few teams engage a coach? How is it imaginable that so many teams with access to coaching fail to make the most of it?

What about your team? Do you have a coach? If so, do you make the most of the coaching you have available to you?

Most Ruby programmers know about Ruby’s interactive console, IRB. (If you don’t, stop right here, open up a command window and run irb. Type some Ruby code. See how it returns the result of each line right away.) IRB is great for poking around with unfamiliar libraries.

Suppose you’re using Capybara with Cucumber for the first time. It would be nice to use IRB to experiment with what Capybara can do on a particular page. You could launch an IRB session and duplicate all the Capybara setup from your Cucumber support/env.rb file. But wouldn’t it be nice if you could just fire up IRB in the context of a step definition so you know everything in your IRB session matches what you’d get in the step def? Turns out you can. Here’s how…

Install the ruby-debug gem. If you’re using Ruby 1.9 like me, you need the ruby-debug19 gem. In Rails 3, just add gem ruby-debug19 to your Gemfile, probably in the test group, and run bundle install.

Require ruby-debug in support/env.rb.

Add breakpoint where you want to jump into IRB. For example:

(Note the extra line after breakpoint with 0 on it. breakpoint breaks before executing the next line, so if it’s the last thing in a block, you won’t jump into the debugger in the context you expect; 0 is a dummy line to keep us in the right context.)

Run Cucumber like normal. When it reaches breakpoint, ruby-debug will take over, and you’ll see a prompt like this: (rdb:1).

You can do a lot of different things at this prompt, but we only care about one right now: type irb and hit Enter. Now you should see a an IRB prompt. You’re in the context of a Cucumber step definition. Type self and hit Enter. You’ll see that self is an instance of Cucumber’s World with various things mixed in. From here, you can do anything you would do inside that step definition.

When you’re done, run quit to get out of IRB and continue to get out of the debugger. Cucumber execution will continue like normal. Keep in mind, though, that if you change the state of your system from IRB, you might not get the test results you expect.

Enhancements and variations for you to explore:

• Make IRB nicer to use with gems such as irbtools
• Create a step definition just for launching the debugger
• Create a tagged scenario just for launching the debugger

The task board is a simple, yet powerful, tool for Scrum teams. As a coach, I can tell a lot about a team just by looking at their task board in the middle of a sprint. If your Scrum team is in the same location, I can’t think of a good reason why you wouldn’t want to build and use a task board.

Here’s how to build a basic task board, various ways to enhance it to convey more information, and some analysis of the many things you can learn from this simple tool.

Supplies Required

• A black or blue poster marker
• A black fine tip marker
• 3 inch square Super Sticky Post-It notes in yellow (generic sticky notes tend not to stick for a whole sprint)
• A large surface (e.g. whiteboard, foam core, smooth wall, etc.)

Optional Supplies

• Blue and red fine tip markers
• Two 1″ photos of each team member
• Larger sticky notes in another color such as blue or green
• Square or small sticky notes in orange or red
• Removable, semi-transparent color dot stickers
• Narrow electrical tape
• Story Definition of Done printed as checklists
• Post-It glue stick
• Blue masking tape

Basic setup and use

Make sure you place your task board where the team will use it. Ideally, the team is in a team room together and the board is in the same room. At the very least, it should be in a place where the team will see it several times a day. It’s very valuable to use the board to focus the Daily Scrum, so there should be enough space for the whole team to stand around it.

On your task board surface, mark out the following columns with marker or tape: Story, Not Started, In Progress, Done.

Create a card (on a sticky note) for each story you committed to in the current sprint. If you have two colors of stickies or a larger sticky available, use that for the stories. Use the black fine marker to write a title for the story in large, clear print. If the story is in the typical “As a , I want so that ” format, you’ll want to shorten it to a 3-6 word title. You can write the full story on the card with a pen if you want. Write the story point estimate on the card, in a different color marker if you have one. The story titles on the cards should be readable from about 6 feet away. Arrange the story cards in priority order in the first column, leaving space between them. Each story thus defines a horizontal lane across the board. (I don’t recommend drawing or taping horizontal lines, though; different stories need different amounts of space at different times.)

Create a card for each task you’ve defined. Again, use the black fine marker and a short title to make them readable from 3-6 feet away. Arrange the tasks in the Not Started column with their corresponding story.

Some teams generate all or most of their tasks at sprint planning. Some generate tasks as they start a story or just-in-time. Still others don’t use tasks at all. If you generate tasks throughout the sprint, you can expand and contract the story lanes to make room for tasks as needed. If you don’t use tasks, you’ll want to eliminate the Story column and move the story cards through the other three columns.

Tasks will almost always be placed on the board in the Not Started column. As a team member assigns a task to himself, he’ll write his name or initials on the card and move the card into the In Progress column. When the task is done, he’ll move it into the Done column and likely choose another task to start.

The basic board should look something like this:

Enhancements and variations

If you have photos for each team member, attach them to small sticky notes or put Post-It glue on the back. Place the photo stickies on the edge of the board to indicate team members available for tasks. I suggest only making one sticky per person readily available. You can have a second sticky available for the rare times a task is blocked and they need to work on a second task. Instead of writing their names on tasks, team members will use their photo to indicate task assignments.

Make a half- or quarter-page checklist for your story definition of done. Print a stack of them. Place one on the board for each story and use it to make sure you generate the right tasks and actually reach done for the story.

If you regularly get work outside your sprint commitment that has to be addressed right away, such as production support, consider adding an “Expedite” lane above the first story. When something new appears in the Not Started column on the Expedite lane, the team focuses on that item rather than stories in order to get it done as soon as possible. (If the “urgent” item doesn’t trump the other stories, it probably should be added to the product backlog and wait until a future sprint, so this rule is a good way to distinguish between truly urgent work and someone just trying to change the team’s priorities mid-sprint.)

Use the red or orange stickies to represent impediments. Place them directly on the items they’re blocking. This avoids the disconnect between an impediment list and the task board and may explain otherwise strange indications on the board (e.g. a high-priority story in progress while low-priority stories get done).

Use different color cards or dots on cards to indicate themes, larger features, dependencies on other teams, etc.

Consider setting a WIP limit, a restriction on the number of stories you can have in progress at once. Post this number in the header of the In Progress column. Note: It’s helpful to write “limit 3 stories” rather than just “3″ because you’re limiting the number of stories in progress even though the column actually contains tasks.

What the task board can tell you

What have we committed to? The stories on the left of the board reflect the team’s commitment for the sprint. Because they’re readable at the 6′ distance, someone can see the overall commitment at a glance.

What’s done? Assuming you’ve created all the tasks for a story to get done, the presence of all a story’s task cards in the Done column indicates that the story is done.

What are we currently working on? The presence of task cards in In Progress indicates that the team is currently working on the corresponding story.

Are we working on the right things? Since stories on the task board are ordered according to their priority in the product backlog, the top stories should be getting to done first. If stories in the middle or at the bottom of the board are done while stories at the top are not started or in-progress, this can indicate a problem. For example, maybe there’s an impediment blocking a high-priority story but no one is talking about it.

Are we working together? The number of stories in progress and the distribution of names reveals whether the team is collaborating or whether each team member is working on her own story.

What’s blocked? If you use impediment stickies, you can see at a glance what’s blocked and make sure something is being done about the impediment.

How much urgent/unplanned work is being added? If you use the Expedite lane, you can see by the accumulation of cards how much work has been added after the start of the sprint. This may lead the team to discuss with the Product Owner dropping one or more stories from the bottom of the board.

What work should I do next? When you’re ready for a new task, the task board can tell you which stories are open so you can find a way to contribute to the highest priority open stories rather than opening a new story.

Next steps

Check out fellow CSC Xavier Quesada Allue’s excellent blog on visual management, which covers this topic in much more detail.

Share in the comments: How have you made the task board work better for your team? Which suggestions from above are you going to try?

You may not realize this: Tables in Cucumber steps don’t have to have a header row. Sometimes it can work really well to use a headerless table of key-value pairs.

Let’s look at an example. Suppose we have a scenario that fills out an advanced search form to search for medical providers matching certain criteria. A mockup of the form looks something like this:

If we were using the recently deprecated web steps generated by cucumber-rails, we might write steps to perform a search like these:

But we know better than to do that, right? After all, we’re trying to describe how the search logic should work, not how the form should look. So we try to write our own steps to do these same thing without talking about the implementation so much, but it’s really hard to get away from the implementation. Even if we drive out words like select, fill in, and click, we still have a step per form element.

Suppose we try to combine them into a single step for the domain concept of performing a search. We might get something like:

The implementation details are gone, but it’s long and hard to read. Enter the key-value table:

In the step definition, we can use the rows_hash method on the table object to convert that key-value table to a single hash. There’s no need to iterate through the rows ourselves. For example, assuming a helper method called provider_search that actually performs the search,

You may have noticed the call to to_bool. This uses a helper method like the following to allow us to use yes and no instead of true and false to make more readable scenarios. Put this somewhere in the support directory.

The call to to_i on the search radius takes advantage of Ruby’s string to integer conversion behavior—if a string starts with an integer but has other text after the integer, the other text is stripped off during the conversion. Try it: Fire up irb (the interactive Ruby console) in a command window and run "5 miles".to_i.

These key-value tables can get long for a complex entity. Not all the details will matter each time. We can make the step read better by introducing a concept of a default provider search. Maybe we have to supply a ZIP code and search radius, but the scenario we’re working on is really about specialties and insurance. We could say,

In the step definition, we’ll declare the default values in a hash and merge it with the supplied values.

If the defaults are well known, this is enough. If they need to be documented, one way I like to do it is as executable documentation with a scenario like this:

If you do this, you’ll want to move the default criteria hash into a helper method or constant to make sure it’s the same hash used in the real scenario and the documentation scenario.

We could make the step definition read better by separating the key and value conversions from the use of the data. Cucumber’s table object has map_headers! and map_column!. Unfortunately, those don’t work for rows_hash at this time. I recently submitted a pull request to make it work. Hopefully, we’ll see that in a Cucumber release soon.