Chapter 16. Refine, Define, and Build
So, now what? If stories are for planning and facilitating discussions in order to build software, all we seem to be doing is lots of talking.
Cards, Conversation, More Cards, More Conversations…
Your first bunch of conversations helped you make sense of an opportunity. You talked about who’d be using your product, and imagined how they’d use it to accomplish something valuable to them. Your conversations went deep enough to break the big opportunity into parts that were small enough that you could tell which parts were important to be in a next product release, and which didn’t matter so much. You collected the stories that described that next viable release into a release backlog.
If you’re clever, and I know you are, your next conversations went deeper into what the software might look like, how it would behave, and how it might knit into your existing product and software architecture. You had these conversations with a close eye on the risky stuff. You sliced up the stories into the parts that you could build early that would help you learn more, faster. And because you’re clever, you segmented your release backlog into stories to take on early to learn, in the middle to build up, and later to refine.
But now it gets real. It’s time to have our best last conversations.
Cutting and Polishing
We’d like to get to work building these things, and we know that building the software that our storytelling describes will go smoothly and predictably if we can concisely describe exactly what we’d like to build. But, after all these conversations, the stories we’re left with feel a little rough around the edges. We likely haven’t talked about any of them in enough detail to understand precisely what they are and what they aren’t, and really predict how long they’ll take to build. But we’ve got a magical machine that’ll fix all this.
I want you to picture an elegantly designed little machine. We’ll drop jagged, rough stories from our release backlog into a big funnel on the left side. Then, inside the machine, we’ll hear a little grinding and clattering. But then out of a little spout on the right side comes small, polished little nuggets. These little nuggets are the things that team members can pick up and use to predictably build high-quality software.
This machine looks magic from the outside. But, on the inside, you and your team are having some serious rock-cutting and polishing discussions. The special, secret mechanism hidden inside this machine is a story workshop.
As you might recall from Chapter 11, story workshops are small, productive conversations where the right people work together to tell the stories one last time, and in the process make all the tough decisions about exactly what they’ll choose to build. These are the deep story conversations that result in confirmation. Finally, we’re getting to that third C in the card-conversation-confirmation flow. And it’s this C that helps us really cut and add the polish to these rocks.
Workshopping Stories
You’ll need a small group that includes a developer, a tester, and people who understand users and how the UI will look and behave—UI designers or business analysts in some organizations. This goes best when the group is small enough to work together effectively in front of a whiteboard. That’s usually three to five people.
This is a workshop, not in a meeting. Meeting is the word that has become a euphemism for unproductive collaboration. A story workshop needs to be filled with lots of productive discussion, hand waving, whiteboard drawing, and sketching. We’ll need to work together to decide exactly what we’ll build. We’ve got to come out of this conversation with solid shared understanding, and we’ll need space to have those productive words-and-pictures conversations.
In all those conversations prior to now, we talked through details, but hopefully we had the restraint to go just deep enough to make the decisions we needed to at the time. The decisions we’re making now focus on answering the question: exactly what will we build?
It’s during this conversation that you’ll find out your story is too big. By that I mean it’s bigger than the ideal size we like to see going into development—a couple of days or less to build. OK, it’s not always too big. But, if you just assume it will be, then you’ll be pleasantly surprised when it’s not. Happily, you have exactly the right people in the room to help you break down this story into smaller stories that can be delivered, tested, and demonstrated in the growing product the team is working together to build.
Sprint or Iteration Planning?
Some Agile practitioners accomplish these critical story conversations during planning sessions like iteration planning or sprint planning. That works pretty well if you’re working with teams that work effectively together and come into the discussion with a good understanding of their product. For teams I worked with for years, that’s the way we did things.
But one of the biggest complaints I hear from Agile teams is that these planning meetings are often long, torturous affairs. At some point everyone agrees on what to build, even if they don’t have shared understanding, just to make this torturous meeting stop.
My first foray into the world of an Agile project team in my role as a business analyst was a cold, hard lesson in the power of collaboration over the written word.
— Nicola Adams
The Context
Recounting a slice of the transformational journey from waterfall to Agile within RAC Insurance in Perth, Western Australia, Nicola—an experienced BA—was well versed in the traditional delivery approach to software development. Her role involved engaging the business, understanding the problem domain, and working with IT to document functional specifications to hand off for delivery. The communication lines were like this:
The focus had been on detailed specifications to try to leave no stone unturned. Recognizing that “developers don’t read,” mitigation strategies were employed (e.g., specification walkthroughs) with variable success. Lengthy time lags were typical from after specifications were completed to when the knowledge was needed to support development and testing.
What Happened Initially?
The natural affinity to written specifications was not easily broken. The concept of fitting requirements on the back of a card was hard to grasp. How could Nicola expect the developers and testers to deliver the required functionality, which she felt accountable for, if they didn’t have sufficient information? The focus shifted to creating story narratives, little different from the functional specifications except in scale; the lines of communication did not change.
Nicola’s elaboration session preparations included:
- Requirements gathering with business stakeholders
- In-depth analysis of requirements and data
- Creating story narratives (one to five pages each) documenting requirements, solution design, and acceptance criteria
- Reading the narratives to the team using a projector and asking for any questions
Unfortunately, the outcomes were not so great. The elaboration sessions were flat and uninspiring, with the majority of the team disengaged. In addition, Nicola felt she had insufficient time to prepare stories, and the team largely ignored the narratives during delivery.
After an elaboration session, Sam, a subject matter expert standing in for the product owner, remarked, “If this is an Agile project, I don’t want to be involved!”
This needed fixing!
What Changed?
Steve, the project manager, facilitated a team retrospective to focus on the problem. This retrospective resulted in a number of key takeaways, including abandoning story narrative documents, including the business and delivery team in story elaboration, and ensuring a set cadence for backlog grooming and story elaboration.
Nicola went beyond simply applying the actions; she fully embraced the intent. The next story elaboration session was a seismic shift from what had preceded.
The team no longer sat bored and disengaged as they plowed through screen-projected story narratives. They were now huddled around visual models and artifacts, engrossed in real story conversations involving the product owner, business subject matter experts, and the delivery team.
The lines of communication had changed. Nicola was no longer the intermediary between business and IT; she was now a facilitator allowing conversations to flow between those who understood the business value, those who sat with the users to know what would be usable, and the delivery team who knew what was feasible:
The business and delivery team loved the new format and were now fully engaged, a shared understanding was created around the problems to be solved, group divergence and convergence enabled the team to arrive at optimum solutions within constraints, and Nicola felt under less pressure and had more time.
Nicola had come in from the cold!
Crowds Don’t Collaborate
The torturous sprint planning meeting has become such a common dysfunction that many teams sensibly choose to have these story discussions in the days preceding the meeting. They often have these scheduled in their calendars as pre-planning meetings, backlog grooming, or backlog refinement meetings. But, too often, what happens is they’ve simply moved the same torture they hated during the planning meeting to a different day. To add insult to injury, team members are asked to take a break from their current productive work to sit through this torture. No wonder they’re not excited about it.
The problem isn’t that story conversations are hard. Well, actually they can be pretty hard at times. But all conversations are made tougher by trying to include too many people. If many of those people aren’t interested or motivated to participate, you’re doomed. You know the people I’m talking about—the ones pretending we can’t see them playing with their smartphones under the table.
Allow team members to opt in to these conversations. If later they complain about the decisions made, make sure you invite them to be there next time.
If everyone wants to participate, try using a fishbowl collaboration pattern like the one described in the following sidebar. This way, interested people can drop by, participate if they want, and leave if they find they’re not missing anything exciting.
If you’ve got people who sincerely want to be involved in the conversation, but adding them expands the conversation past a productive size, try using a fishbowl collaboration pattern. This’ll give them a way to be involved with minimal impact to the outcome. What they and others often find is that being there wasn’t as important as they thought. Over time you’ll see that they’re happy to let others discuss the details and then learn about the results in a later conversation.
The process works like this: three to five people work together in front of whiteboard or flipchart paper—they’re the fish in the bowl.
Others in the room may observe but not speak. They’re outside the bowl.
If someone from outside the bowl wants to participate, she can “jump in.” But, when one outsider jumps in, one insider must simultaneously jump out.
In this way, the conversation stays small and productive, and others stay informed and involved. It’s also a great way for learners to get up to speed without slowing down work.
Split and Thin
Remember the cake and cupcakes discussion from Chapter 8? Now’s the time to break down those cakes to the smallest cupcakes you can. It’s now—when we’ve got developers, testers, and others who can really build the software—that we can really imagine how we could break down the story.
Remember that software is “soft.” Well, it’s not soft like a sponge or a cupcake. Ideally, it’s more like a rather large document or a book. If you were writing a book, like I’m doing my best to do right now, you wouldn’t try to do it all at one time. You might sit down and write a chapter at a time. In fact I’ll write a chapter at a time, and Peter, my competent, supportive editor, will review what I’ve written and make corrections and suggestions.
But then the chapter’s not “done.” Far from it.
I’ll need to go back through and figure out where there should be illustrations. I’ll need to figure out if I should add footnotes, references, glossary terms, or index items. Then other editors from the publisher will go back through each chapter, making final refinements. I’ve naturally split up the work to do it iteratively so that I can see the whole book take shape sooner.
You’re reading the “Refine, Define, and Build” chapter. And if you’re reading it now, it’s hopefully fully baked. If I were to think about my final acceptance criteria, I’d say it should be:
- Edited and understandable by me
- Edited and understandable by my editors
- Supported by illustrations that help enable readers to visualize points
- Supported by an index readers could use to find terms in the chapter
- Supported by a glossary that readers could use to look up definitions of terms introduced in the chapter
Crap, that’s a lot of work. Even as I type those things into the first draft now, I realize I’ve got lots of work to do. But I don’t want to do all of it before moving on to the next chapter, because I’d like to see how the whole book is hanging together. So I’ll break it into “cupcakes”—small, complete parts that aren’t ready to ship, but that boost my confidence that I’m on the right track as I move through this book.
I’d break down my work into stories like this:
- Refine, Define, Build first rough draft
- Refine, Define, Build second refined draft
- Refine, Define, Build with illustrations
- Refine, Define, Build with reviewer feedback incorporated
- Refine, Define, Build index terms
- Refine, Define, Build glossary terms
- Refine, Define, Build final draft
Each one of those things I can tell a story about describes what it looks like, and thinks through the steps I (with Peter’s editing assistance) must accomplish to finish each of these smaller versions and improvements to the chapter. And you can see that as each thing is completed, the chapter gets progressively more refined and closer to releasable. In theory, there’s something you could see and consume after the first story in the list is done. But I wouldn’t do that to you. It wouldn’t be pretty, and your reactions wouldn’t be good.
Finally, since I know you’re on top of your game, you may have noticed that the list of smaller, cupcake-sized stories looks a lot like the acceptance criteria for the chapter. That’s the magic here. It’s the discussion of the acceptance criteria that reveals how we could break down the work into smaller parts we could create and inspect along the way.
It’s important to inspect your work along the way so you can evaluate it and make course corrections. You should have seen the really stupid example I’d originally written here. But you’ll never see it because I wrote it, inspected it, and then removed it.
In a traditional software process, that “inspecting and removing” stuff would be called bad requirements. But, when you’ve got your Agile hat on, it’s just learning and iterative improvement.
One of my favorite simple techniques for splitting stories more finally is the Good-Better-Best game. We played this game using a big story and sticky notes and ended up with this:
Good Enough for Now
Given a story, start by having a discussion about what’s just good enough—barely sufficient, really, and probably not good enough that users or customers would love it. Write down characteristics that would make it good enough and treat them as separate, smaller stories.
In walking through an example that’s something like IMDb.com (the Internet movie database), we discussed the “View movie info” story. We imagined a screen where I could look at movie details so that I could make a decision about seeing the movie. When we discussed Good, we came up with these simple things:
- View the basic info: title, rating, director, genre, and so on
- View the movie poster
- Watch a preview
Better
Then ask what would make it even better. For the movie database example, we ended up with things like:
- Read a movie synopsis
- Read member ratings
- Read reviewer ratings
- View a list of all the actors in the movie
Best
Finally, ask what would make it really fabulous. Don’t be afraid to go crazy here. Remember, these aren’t the requirements. This is just you and your team considering options. Some interesting things sometimes come from these discussions—things that might make the product really fabulous, but are surprisingly cheap to implement. For the movie database example, we ended up with things like:
- Watch alternative previews or videos about the movie
- Read trivia about the movie
- Read news about the movie
- See and participate in discussions about the movie
You can see how this progression of smaller stories helps build the “View movie info” story up from something that will let me just see it work, to stories that would improve it to make it really fabulous. If I were building this feature, I’d do the basics first across the whole application before I moved on to making things better and then best. I just feel safer meeting deadlines when I build that way.
When you’re really having good story discussions, and I know you will, at the end of a story workshop you should have right-sized stories supported by lots of extra documentation and models, and by acceptance criteria that describe how you’ll check this story to confirm it’s done. Sometimes it’ll take a couple of workshops supported by a little outside research, analysis, and design work to arrive at agreement, but that’s OK. Cutting and polishing takes time, and a bit more patience.
Use Your Story Map During Delivery
Use a map to build shared understanding with your delivery team. I often hear from team members working in an Agile process how much they like collaborating, and how productive they feel because every week or two they see and demonstrate working software. But then they follow that up with statements like, “I feel like I’ve lost the big picture. All I see are these little parts of the product we build.” Use a map to give the team the visibility of the whole product or feature you’re working on. They’ll make better tactical design and development decisions if they understand the context those decisions fit into.
Use a Map to Visualize Progress
As you begin to build your product release, the map makes a good visual dashboard to show what you have and haven’t built.
Some teams remove detailed stories from the body of the map as they bring them into development to complete. That way, when they look at the map, all they see is what’s left to build.
Other teams like leaving the map in place and using pens or colored stickers to mark the stories they’ve completed. When they step back and look at the map, they see a visualization of what’s done, and what’s left to do.
Use the map to identify the next stories to build. Every week, product owners will need-assess the progress of ongoing development work, and make decisions about what’s important to focus on next. When the map visualizes progress, then it’s a bit easier to scan it to look for areas that need more focus. It’s sort of like being a painter. If you can step back and take in the entire painting, it’s easer to figure out where to start working next.
Use Simple Maps During Story Workshops
Each development cycle, you’ll identify stories in the map you should work on next. You’ll carry those stories into those last best conversations you’ll have during story workshops.
An easy visualization to build during that workshop is a simple map. You might be mapping only the three or four steps the user takes using a feature you’re discussing. But being able to point to sticky notes on a wall that show the flow helps the discussion move faster. As you begin to discuss acceptance criteria, write them on sticky notes and add them into this mini-map. In the end, you’ll have a simple visualization that supports the conversation you had in this workshop.
As the Obama 2008 election campaign proved, the Internet has forever changed politics. Barack Obama’s online strategy played a direct and significant role in his nomination and subsequent election. The strategy for the 2012 election was to provide tools that supported traditional grassroots organizing and fundraising, while using technology as a “force multiplier” to counteract the massive amounts of third-party money entering the race. While we used tools like Pivotal Tracker and Basecamp to track the work our teams did to support the 2012 Obama Campaign Dashboard, to really help everyone else understand what was going on we used walls full of sticky notes. You might ask, “Why would you take the time to mess around with a bunch of Post-its on the wall?” Here’s why.
We had two different cultures working together in the same space on this effort. We were the folks in the corner who unscrewed the light bulbs so we could work in relative darkness; who brought in our own noisy keyboards; who wore gigantic headphones to drown out the buzz of cable television interviews, bells, and handclaps that permeated the open newsroom-style office; and who wore metal band t-shirts instead of seersucker suits. All the people who’d worked on previous campaigns, the guys in suits, came in with a traditional view of software development. “We describe the features we want, and you build them for us. Yesterday.” They weren’t used to receiving things incrementally and seeing them iteratively change and improve, and they definitely weren’t used to making the tradeoffs required to get the stuff they really needed when it had the biggest impact. It’s a campaign. There’s no extending the delivery date, except by act of Congress! The day after the election, it’s over whether we’re finished or not. And there was no way they’d get everything they imagined.
When we originally got started, we used some basic mapping approaches to describe the people using our system and the different kinds of things they’d need to do. We could then organize the work into releases over time. This worked OK, but it was hard for the people leading the campaign to really get engaged with thinking about the way people would work later, more than a year from the present day. Their heads were focused on what they needed to get done now. And they were making lots of guesses about what volunteers and group leaders would be doing. They had to, especially if we were reimagining the way they worked.
After seven months, we shipped a small, minimum viable product—just enough to release to our first users in Iowa. That’s when everything changed. The immediate reaction was bad because what we released clearly wasn’t everything people envisioned it would be. There were lots of important things missing. It had bugs. We heard a lot of “Why didn’t you get it right the first time?” As much as we assured them we’d be fixing broken things and improving things every single week, they couldn’t really buy it until they saw it. But as things quickly did improve, that really built trust.
That’s where the big wall of stickies comes in. We used Pivotal Tracker and Basecamp, but all these other people weren’t going to use those tools. We needed a fully transparent way that everyone could see what we were working on, and what was coming. Our wall of stories was organized left to right by calendar week, and top to bottom by priority. We were all focused on time. There was a big clock on the wall counting down the minutes until the election. They all knew that some things were less important now, and some even more critical as election day got closer. Every story on the wall was color-coded for the activity the idea affected—like Field Work, Team Building, Voter Registration, and Voter Turnout. There’s a lot of purple in this picture because it’s early, and Team Building, represented by the purple stickies, is more important than other things like Voter Turnout right now.
When we added things to the board, we did it together with the people running the campaign. We talked about what was already planned for that week, and what the odds were of it making it into the week’s work. We talked about the real problem being solved behind the feature idea. Together we decided how important it was relative to all the other things on the wall. When it came time to build the software, the developer responsible would work directly with the stakeholder who knew the most. They’d work together to figure out the details. Sometimes all it took was lots of scribbling on a whiteboard to agree. Sometimes we’d take a day and build some simple UI prototypes.
This big visual wall of sticky notes was critical for building a bridge between the people developing the software and the people who needed it. It’s what they needed to help them visualize what was going on and when, and to actively participate in making decisions.