Breakout Group Conversations

Once the most popular topics were decided, the originator of each one found a table and other participants came and joined them for a group discussion. Everyone talked for ~30m, and each group was asked to generate some sort of artifact for public consumption. After the conversations, a member from each breakout group presented their poster to the assembled group.

What the @&#*!? is ‘Cynefin’? (It’s Complicated)

Fishbowl

After a break and a bit more brunching, the remaining highly popular topics were used to feed the Fishbowl. A Fishbowl is a conversation format where four seats are set up for a conversation among three participants. If someone from the audience wants to speak, they come on stage, join the panel and take the fourth chair, whereupon the longest-sitting panelist retires to the audience. In this way, a democratic, collaborative group conversation can be had.

Closing Circle

It was a great day of conversation, but everyone was pretty beat. And the weather outside was gorgeous! We formed up into the hallmark end of a Balanced Team event: the closing circle. Each person described one thing they’d take with them from the event, into their work.

In How To Manage A Design Backlog, I talked about some of the general ideas behind managing design work on teams where developers use an agile, XP-based backlog. In How To Integrate Design in an Agile Backlog, I talked about the specifics of integrating design stories into that development backlog. In this post, I’ll talk about how to maintain a separate Design backlog.

Recall that:

In the past separate design backlogs have been prohibitively difficult to integrate into an agile team’s workflow…Now that it’s feasible, a separate Design Backlog is appropriate when you have multiple platforms (e.g. iOS and Android) with design concerns which are independent of platform, or when it’s important to estimate design work without affecting development velocity.

A General Flow for separate Design and Development backlogs

So what does this all look like in practice?

Using the Multiproject Workspace

Tracker New offers a Multi-Project Workspace View which is key to unlocking the power of a Design backlog. Your Multi-Project Workspace should include the project Design backlog, as well as the various project development backlogs.

As with an Integrated Backlog, designers’ first responsibility is to ensure that development isn’t blocked by design. Review the development backlog for “blocked by design” stories. For the most part, these should be minor design tasks: cutting assets or interpreting already-made design decisions. Anything larger than that should be cut into a story for the Design Backlog.

Using the Design Backlog

The Design Backlog should first focus on stories which address design independent of platform. Interestingly, this may affect team workflows. On one project, we used to maintain separate files for iOS and Android workflows, e.g. Hamazon-Order-History-iOS.ai and Hamazon-Order-History-android.ai, with stories in the iOS and Android backlogs corresponding to separate files. Once the Design Backlog comes into play, it makes more sense to organize files and make design decisions by user flow, and have separate artboards for the various platforms. Stories might start by focusing on upcoming epics and stories for which design is unknown to figure out the main user mechanics, visual metaphors, and design decisions, and then break out smaller stories to customize for each platform.

Prioritization & Estimation

The biggest danger in a separate Design backlog is dependency tracking. Make liberal use of epics (ubiquitously-named across all backlogs) and linked stories. Make sure to prioritize so that design is a week or two ahead of development. Furthermore, now that the design backlog is clear of development velocity, there’s no reason not to estimate design stories. This is incredibly powerful: not only do we start to have a much more accurate picture of how much design work there is to do and when design work will be done, but estimation forces a cleaner definition of what “done” means for a given design story. This in turn helps to build a practice and culture of sustainable pace in design. But Prioritization and Estimation involve non-trivial amounts work; when do we find time for it?

Design Standups & IPMs

Standup meetings and Iteration Planning Meetings are hallmarks of Agile practice. Now that we’ve got a Design backlog, Design Standup and Design IPM fall out naturally. However, we want keep to the fewest responsible number of meetings. We’ve found that a ~5m design standup with the product team, immediately after team standup, is a good opportunity to review in-flight and upcoming stories in the backlog, get on the same page, and discuss pairing for the day. It often makes sense to do acceptance and estimation as well. Design IPMs can occasionally be scheduled, but often they’re subsumed into other meetings, particularly Pre-IPM. Since Pre-IPM often involves grooming the backlog and looking ahead to future epics, it’s a natural time to review the design backlog and ensure priorities are in sync. Occasionally a separate Design IPM will be called for, but this will probably only happen every 3-5 weeks. With proper management of the Design backlog, this helps scale a healthy, sustainably paced design practice for large projects across multiple platforms.

In How To Manage A Design Backlog, I talked about some of the general ideas behind managing design work on teams where developers use an agile, XP-based backlog—i.e., a Pivotal Tracker-based workflow. In this post, I’ll talk about the specifics of integrating design stories into that development backlog. Recall our goals are that:

design should not block development,

design should know what to work on next,

design can forecast when design decisions will be made,

design might help drive out product vision.

First we’ll discuss when to include design stories in a development backlog, then I’ll classify a few types of stories (and the design work that needs to be done on them), and finally we’ll discuss typical rhythms on a project.

When should I use an Integrated Backlog?

An integrated design backlog is appropriate for small- to medium-sized projects (i.e. teams which can be fed with two or fewer pizzas), focused on a single platform. It can accommodate teams which have designers that code, as well as designers who don’t.

Pros and Cons of an integrated backlog

PRO: simple, easier to see prioritization

CON: no design velocity

In the past separate design backlogs have been prohibitively difficult to integrate into an agile team’s workflow, primarily because tracking dependencies across backlogs was too difficult. The game changed when Pivotal Tracker launched its new Mult-Project Workspace View. Now that it’s feasible, a separate Design Backlog is appropriate when you have multiple platforms (e.g. iOS and Android) with design concerns which are independent of platform, or when it’s important to estimate design work without affecting development velocity.

Development Stories for Which Design Is Complete

Design decisions communicated by sketches or comments and supported by a pattern library accompany a well-formed story.

These are development stories in the backlog, with design decisions delivered by attaching mock-ups or comments. It’s helpful to attach a mock or whiteboard photo to the story to 1) make it easy to find the visualization in IPM, and 2) to assert that design decisions have been made. It can be helpful to attach links to mocks and assets in dropbox or pixellapse, but these should be for context only, and not the final deliverable. While it can be helpful to attach documentation to the epic itself, the best practice is to be explicit about where the developers need to look to find design documentation—ideally, within the story itself—and to reduce the number of places they need to look.

Blocked by Design

Regular development stories may have a “▒ blocked by design ▒” label. This label is usually applied in IPM or when the story is in-flight and the developers realize they’re blocked. When applying the label, it’s crucial to write a comment specifying what will un-block the story. Usually this will be “blocked pending asset” or “blocked pending a decision from design about whether it’s ok to combine these two screens into a single form.”

Design-Only Stories

These are stories in which design is (more-or-less) known, but not articulated. Sometimes rough sketches may exist (e.g. whiteboard wireframes or descriptions of design decisions), but designers feel it’s worthwhile to step through the whole user flow. Mocking up known ideas with the actual visual design can help drive out problems and edge cases. Usually this will be done by pasting a Gherkin story into the comments of an Illustrator doc, and then filling in the screens with screenshots of working software, aided by wires or mockups. Occasionally, when interaction design is especially important, the final deliverable may be a click-through prototype.

In the backlog, these stories should be labeled “design-only”, and estimated at zero points. Design stories are a little different than development stories. These stories may include the “As a [USER]…” and “Given…When…Then” Gherkin of the [Well Formed Story][] structure, but the titles lack the Well-Formed “…should…”. Instead, the title describes what needs to be done to make design decisions. Story titles often include the word “flow”: Mock up [FEATURE] flow or Flesh out user flow for [FEATURE]. When the mock-ups have been created, designers will attach them with a comment mentioning any major issues (“we decided on the second approach discussed earlier, and you can see it works both for guests and logged-in users”) and mark the story as done. Because it’s a zero-point story (and not a chore), someone will need to accept it.

Why Zero Points?

We usually estimate these as zero-point stories because we want to ensure there’s a moment to check-in with the product team —acceptance—but we don’t want to have design points skew development velocity. This often changes on projects where the design resource also does development. E.g., on a project where a designer also works on pointed features (usually front-end development), we want to reflect the fact that design work is taking away from development points that would otherwise be earned. In these cases, the designer must do their best to estimate design stories. It’ll usually be a bit of a guess, but hopefully its a small enough number of points to account for work without skewing velocity.

Epics & Stories for Which Design Is Unknown

In some cases, there’s a loose product goal, but the team has not yet agreed on the best way to get there. In these cases, investigate. These stories often entail product and design getting in front of a whiteboard and sketching. The result is often a flow rendered on the whiteboard, with enough context to write stories. Once Investigations are complete, the flow can be added to the epic. Product and Design can review the mocks and generate development stories (this is a great use of a Pre IPM meeting).

Design Acceptance

How do we get to accepted stories? At the beginning of a story, designers will click “start”, do the work, and click “finish” when they’re happy with their design decision. They’ll attach documentation (usually wires or whiteboard photos) and make a brief comment to the effect of “we’ve got a direction we’re happy with, ready to talk to product”, and then click “Delivered”. Product (or the client) will then sit with the designers and review the mocks.

If Product likes the flow, they’ll click “Accept”.

If Product mostly likes the flow, but some minor changes are needed, they’ll click “reject” and indicate what changes are necessary for acceptance. “Rejection” can be a harsh word, but in the context of Agile it’s not bad—it’s just one of our feedback loops.

If Product feels the flow really doesn’t work, that usually means the first attempt was necessary to drive out new questions and problems that were not apparent at first. In this case, click “Accept” on the story, and write a new story called “[OLD STORY NAME] version 2”, and note the new requirements and learnings based on the first story. We do this to reflect the work done on the initial story. Because determining a definition of “done” can be difficult for design, it’s important to mark the progress of work, and to avoid a design story that’s constantly open. Expect to see no more than one or two rejections on a story—either you’re finding design solutions, or learning things which inform your next design decision.

Converting stories from Design to Development

So: a design story may progress from a rough idea through an investigation into a design solution. When this is the first story of it’s epic, it may be useful to convert the design story to a development story. This can be helpful when a lot of the design thinking and history and mock-ups are captured in the comment thread of the story. This is done by clicking “Accept” on the story—we want to honor the work and capture the history—and then unstarting the story, and renaming and re-writing it as a Well-Formed development story, at which point it’s prioritized by Product and estimated at IPM.

A General Flow for Agile Design

So what does this all look like in practice?

When Design Blocks Development

Let’s take the simple case and start from the beginning: a green-field project that’s starting fresh. The project will kick off with an agile inception, which results in a prioritized and estimated backlog. Usually, the stories in this backlog will embody a few larger themes, or epics, and designing those flows is about the right level of fidelity for this round of design. Designers start off by picking up the first epic and sketching userflows on the whiteboard. With a few of those done, the team should have a rough idea of a layout for the app, and developers should have enough context to start building working software. Design is no longer blocking development.

Using Design Stories

Now that development isn’t blocked by design, designers can shift focus to higher-level design concerns. Often, this will mean creating a visual system (which might be is enshrined in a style guide). This places us at the beginning of a Big Design Refactor cycle.

The Product / Design team can then go through the backlog, updating unstarted development stories with the newly-decided-upon visual design, and creating new stories to skin already-built functionality using the new styles. In an ongoing project, this story-wrangling probably happens in a Pre-IPM meeting.

As new epics are created by Product, stories can be written to flesh out new user flows. Usually just focusing on the Happy Path is sufficient, but notable edge cases may also deserve inclusion.

Normal Workflow

Designers start the day by going through the development backlog, looking for “▒ blocked by design ▒” stories. This is analogous to developers checking that the build is green before starting the next story on top of the backlog. If the development backlog is clear of blockers, designers will pull the top story labeled “design-only”. Over time, the project will build up a visual system, add new epics and features which break the system, and refactor the system.

This is one way that proper management of design stories leads to a healthy project at a sustainable pace. In the final installment of this series, we’ll tackle techniques for separating design stories into their own backlog.

Every project is different, but Agile and XP have taught developers a stable and robust set of tools for managing (development) work. What about managing design work? (With apologies to Tolstoy :)

[Development backlogs] are all happy; every [design backlog] is unhappy in its own way.

A designer colleague asks:

I’d love some insight into how other people use [Pivotal Tracker] / attach mocks and keep things updated as stories split and get added. I’d love to learn how to spend more time working on design rather than managing it.

There are many approaches to managing design and integrating design work with development work. I’ve seen projects where Design stories are comingled with development stories in a single backlog (both pointed and unpointed), a separate Design backlog, and an unpointed, kanban-esque (Trello) backlog. I’ve tried index cards, tried Basecamp, tried Excel, and tried just keeping a todo list. Different approaches tend to work better than others, mostly dependent on project type, project phase, and team constitution. How large is the team? How many people are focused on development? On design? On product or biz-dev? How many people switch between multiple roles?

doing rough design (without a design system) to unblock development, and then

iterating on product, and then

building a design system as more is learned about the domain.

Some time before each Big Design Refactor, the design system will break and this cycle will repeat—which is to say, these steps are sufficient to cover all phases of design.

When should I Integrate Design with a Development Backlog?

An integrated design backlog is appropriate for small- to medium-sized projects (i.e. teams which can be fed with two or fewer pizzas), focused on a single platform. It can accommodate teams which have designers that code, as well as designers who don’t.

Pros and Cons of an integrated backlog

PRO: simple, easier to see prioritization

CON: no design velocity

When should I use a Separate Design Backlog

In the past separate design backlogs have been prohibitively difficult to integrate into an agile team’s workflow, primarily because tracking dependencies across backlogs was too difficult. The game changed when Pivotal Tracker launched its new Mult-Project Workspace View. Now that it’s feasible, a separate Design Backlog is appropriate when you have multiple platforms (e.g. iOS and Android) with design concerns which are independent of platform, or when it’s important to estimate design work without affecting development velocity.

Pros and Cons of a separate design backlog

CON: tracking dependencies between design and development stories becomes difficult

Given these problems and principles, I’ve found effective techniques for managing design stories within a development backlog, and another set of techniques for managing a separate design backlog. Stay tuned for Parts 2 and 3.

As a business, design is built around deliverables: clients pay for wireframes, mockups, prototypes. As a practice, these deliverables are a means to a single end: communicating design decisions. The Agile Manifesto prefers “Working software over comprehensive documentation”, so why are designers spending time on artifacts the user will never see? Agile seeks to minimize waste, so taken to its logical extreme, all documentation is waste. That doesn’t mean documentation can (or should) be done away with entirely; it’s necessary for teams to function (particularly at scale). But it does suggest that minimizing documentation is a Good Thing, and that designers ought to be seeking to communicate design decisions with the least amount of work possible. Welcome to the Minimum Viable (Design) Deliverable.

With Apologies

We are uncovering better ways of designing experiences by doing it and helping others do it.
Through this work we have come to value design decisions as the fundamental unit of work for designers. We prefer to communicate design decisions by:

Comments over Wireframes,

Wireframes over Low-Res Mocks,

Low-Res Mocks over High-Res Mocks,

A Few DRY High-Res Mocks, Supported by a Live Styleguide, over Exhaustive High-Res Documentation

That is, while there is value in the items on the right, we value the items on the left more.

Using the Minimum Viable Deliverable

It’s easy! All you need to do is 1) socialize the idea that “less artifact can be better” among your team, and 2) always ask the question: what’s the least amount of deliverable that we need right now? Is a high-resolution mockup really the only way to communicate that design decision? Could we get away with describing the design decision in a sentence, and then using the saved time to work through other design decisions? Or to implement some of the design? Making this question a regular part of your design process can greatly speed up your team’s Think-Make-Check loop, reduce the amount of high-resolution drudge-work, and make more time for the fun part: digging into design problems—and solutions.

Many people new to building apps fall in love the moment they learn about the idea of a Minimum Viable Product. “It’s minimal! So there’s less risk. And it’s viable! So it’ll prove something!”. Unfortunately, it’s easy for the line of “minimum” or “viable” to slip. How can a team stay focused?

Lean Hypothesis are an effective way to help the team connect the problem they’re trying to solve to the product they’re building. They take the form of

"We believe [TYPE OF USER] has a problem [DOING THING]. We can help them with [OUR SOLUTION]. We'll know we're right if [CHANGE IN METRIC]."

Let’s say we’ve got a problem on Hamazon, our e-commerce platform. Users are clicking around and spending lots of time-on-site, but they’re not putting items in their cart and converting. We might start with

"We believe SHOPPERS have a problem CHOOSING FROM THE MASSIVE SELECTION OF PORK PRODUCTS. We can help them by SHOWING RECOMMENDATIONS FROM OTHER SHOPPERS. We'll know we're right if SHOPPERS ADD ITEMS TO CART MORE QUICKLY".

Once we have a hypothesis, an MVP can be defined as the least amount of work we can do to in/validate the hypothesis. We started from the assumption that we need a recommendation engine, but rather than building it out (an expensive proposition), we’ve honed in on the a more specific problem: shoppers need guidance. For much less effort, we could test this hypothesis by curating and featuring a small selection of recommended products—this “Recommended Products” section is our new MVP! This might fail to impel shoppers to add items to their cart more quickly; if so, we’ll try a different hypothesis. (Notice we didn’t incur the cost of building a recommendation engine!). But if it succeeds, we’ll be able to iterate. Maybe we find that the Recommended Products converts very well for users from the east coast, but not so well for users from the west coast.

"We believe WEST COAST SHOPPERS have a problem WITH THE RECOMMENDED PRODUCTS WE'RE CHOOSING. We can help them by GIVING DIFFERENT RECOMMENDATIONS. We'll know we're right if WEST-COAST SHOPPERS ADD ITEMS TO CART MORE QUICKLY".

So now our MVP would be a feature that lets our in-house curation team target separate Recommendation sets based on geography. We’d continue to iterate, and it’s possible our recommendation targeting would get so specific that we’d end up building a recommendation engine, but we’d only do so if the business needs led us there, rather than our intuition. In that way, we’d iterate towards a truly minimal, truly viable product.

Hamazon, your Fine Purveyors of Pork Products since 2010, is the default example I use so as to have a consistent example of a software application whenever I tell stories. In the spirit of Convention Over Configuration, it’s helpful to have a go-to narrative rather than inventing a new example for every story. Because Hamazon bears striking similarities to a certain e-commerce site, most people grok it quickly, and because the default Pivotal Tracker Sample Project is an e-commerce site, it’s easy to quickly generate a new Hamazon backlog at any time.

Create a fully-fleshed out e-commerce sample project in Pivotal Tracker with a few clicks.

Design assets, mockups, and that sort of thing in the /doc folder. This is where I get most of the value of Hamazon these days.

The rest of this repo is a very old Spree install that I modified for cosmetic purposes. I haven’t tried to run it in years. One of these days I may update it (if I ever need to).

It’s my hope that others will start using Hamazon and contribute back to it. Code contributions would be welcome, but even just using it spreads the benefits of Convention Over Configuration. It helps to eliminate the trivial choice of “what’s the example I should use to describe [SOME ARBITRARY] concept?”, and frees you to think about explaining the concept, not framing the situation for the listener.

True Story

Once upon a time, there was a client who struggled with the Agile process. It’s not that he wasn’t smart and curious, and it’s not that he didn’t want to build a great product in a domain he knew lots about, but he had a thorny problem: because he was successful, and because he was smart, he just wanted to build this new digital product the way he’d successfully built (non-digital) products before: top-down and waterfall. He didn’t want to make decisions about the details. He refused to look at Pivotal Tracker.

He came to us because he’d heard “Pivotal’s the best”, but he didn’t put together that the process—pairing, testing, short feedback loops, collective ownership of the product, writing the smallest possible stories that deliver user-facing value—were the reason we were successful. We tried to educate, we tried to make the case, we tried to explain Agile, but nothing really worked. He didn’t have the patience, and he just wanted to know why we weren’t building a product that was perfect.

Everything Changed

One day, a Pivot on the project printed up the Agile Manifesto and hung it on the wall. That’s it. Nothing else.

Nothing happened the first day.

Nothing happened the second day.

On the third day, the client, of his own volition, pointed to the manifesto and asked a question: “What’s that?”. We started to tell him, and that opened up the conversation. He was smart and inquisitive and curious, and the more he learned about Agile, the more he understood why we insisted on tight feedback loops, small stories, and user feedback.

The moral of the story: post your principles. Make them public. Let everyone see them. Make them a part of the space you inhabit, and it becomes a little easier to make sure they’re present in your practice.

Meetings are crucial to healthy team communication. But they’re also opportunities for waste, occasionally dull, and always expensive. Every team is different, but continuing the theme of “Convention over configuration for process”, I’ve found the following structure keeps meetings to ~7.5% of your week. This minimizes waste, maximizes making-time, and makes for a nice scheduling default for projects.

1. Daily Standup

5x weekly, 10 minutes each

Standup is a short, team-wide orientation meeting. Each morning, the team meets for a the Team Stand-Up meeting. As it’s name implies, everyone should be standing up—even if they’re remote and parked behind a screen. Meetings tend to run short when everyone’s on their feet, and there isn’t much to cover anyway, just three canonical questions:

What did you do yesterday?

What are you doing today?

Are you blocked on anything?

Since the team is pairing, most of the time the second person will say “pass” since their pair already mentioned the stories they worked on, the issues they had, and what they’re doing next: sticking together or seeking a new pairing partner.

2. Iteration Planning Meeting (“IPM”)

1x weekly, 60 minutes each

The IPM is a weekly tactical planning meeting. It’s aim is to ensure that the backlog is in good shape, and that all the team members have a shared understanding of what the stories mean. The product manager leads the meeting by reviewing the backlog. Each story should be reviewed; questions can be answered, clarifications can be issued, and developers can estimate the stories. Ideally, the meeting is on Monday or Tuesday and the team will get through the current iteration’s undone stories and a healthy chunk of next iteration’s stories. On some teams, it helps to take an hour before the IPM to groom the backlog, prioritize, and flesh out poorly-worded stories, and review mockups for hidden features in a pre-IPM meeting with a small group (usually the Product Owner and a single developer).

3. Friday Afternoon Meeting

1x weekly, 60 minutes each

A useful pattern on recent projects has been to block out an hour Friday afternoon and rotate between three meetings: the Team Retro, the Tech Retro, and the Release Planning. It’s nice to have a regular time, and every-three-weeks is about the right frequency for each of these.

Week 1: Team Retro

The Team Retro is a chance for the day-to-day members of the team to reflect on how things are going, celebrate successes, voice frustrations, and suggest Action Items. While there are plenty of variations, the classic Retro format is to throw three columns on a whiteboard:

“Smileys”, or things that are going well, represented by the expected emoticon :-)

“Frownies”, or things that are going poorly, represented by :-(

“Mehs”, or things that don’t fit cleanly in either category, but bear mentioning :-\

After ~25m of going around the room and throwing out Smileys, Frownies, and Meh’s, the team might spend a few minutes identifying items which have a common theme, and then spend the rest of the time suggesting action items, either for each item (starting with the Frownies) or, if time is short, on a theme-by-theme basis. The action items are recorded and assigned to individuals, and their progress is followed (often at the start of the next retro). For more about Team Retros, see 7 Best Practices for Facilitating Agile Retrospectives.

Week 2: Tech Retro

A Tech Retro is for and by developers. While pair-programming is essentially continuous code review, it can still be useful to take some time to step back and look at the codebase. Tech Retros often take the traditional “Smilely / Frownie / Meh” format, but focus exclusively on the codebase. This is a great time to talk about modeling decisions and suggest refactors. Often the action items resulting from tech retros are a long list of chores. Try to keep each one to a manageable size, and make sure at least a few of them make it into the backlog for the next iteration.

Week 3: Release Planning

“Release Planning” means different things to different Agilists, but in this context it’s a loose title for a long-range planning meeting. While the IPM is a short-term tactical meeting, it’s important to occasionally step back and look at the big picture. What are the product’s medium- and long-term goals? Are we on track? What should our next milestone be? The Release Planning should be attended by the whole team, and by the stakeholders like clients and CEOs who may not be part of the day-to-day workings of the team. It’s a chance to review epic story tracks, dates and deadlines, and to make sure that everyone has a shared vision of where the team is going—and that it’s a place worth going to.

Why Meetings Matter

Communication is crucial, but so striking a balance between waste and on keeping everyone on the same page. I’ve found that teams which hew to this schedule tend to have a healthy rhythm. While circumstances occasionally require additional meetings, especially on the part of the Product Owner or the outward-facing members of the team, this structure is sufficient to maintain healthy intra-team communication without taking developers away from code any more than necessary.

Do you have another default meeting structure that you like? Let’s hear about it in the comments!

Facilitating a retro is a very powerful role; it’s almost akin to being a courthouse judge (and stenographer). By asking questions, recording testimony, and shaping the debate, you mold and influence your teammates’ feedback in a very vulnerable and trusting space. If the Product team sets goals (like a Legislature) and Development and Design teams implement them (like an Executive Branch), a retro is a chance to reflect, interpret, and set future direction—not unlike a Judiciary. In practice, that means it’s important to be especially honest and impartial, and to double-check that you’re doing justice to the team’s best interest and the speakers’ intent. Here’re a few patterns I’ve observed that help make the difference between a good retro and a bad one.

1. Explain and Enforce format

At the beginning of a retro, take a minute to explain what’s going on—even for a seasoned team, but especially for a team with new members. “We’re here to reflect and improve on process—this is a safe space, and we’re oriented towards exposing issues and taking action.” If the team isn’t explicitly aligned on why they’re in the room, they can’t get the job done. Speaking up is high value (it ensures the retro is properly oriented) and low-risk (it only takes a minute).

2. Write Everything Down Verbatim

A retro is about listening. Whoever takes notes ought to be respectful of the speakers voice. That means recording their thoughts as faithfully as possible, without interjecting opinion or commentary. If you do need to paraphrase for brevity, be as faithful to the original comment as possible—don’t insert your view, you’ll get your own turn—and confirm that your version does justice to the original. “You said ‘INSERT COMMENT HERE’ and I wrote ‘INSERT PARAPHRASE HERE’. Is that right? “

3. Categorize carefully

If you choose to categorize items, be very conservative about pre-judging what it is you’re talking about. Sure, you’ve spent the last 25 minutes talking about a few categories, but don’t jump to putting names on the buckets—that’s prejudice, and it shapes opinions. Group like items (“Are these two frownies related?”), branch out from there, and labels will emerge. Be careful that the buckets aren’t too broad to be useful; it can be tempting to draw connections among almost everything, but ideally you’ll be slicing things a little thinner, facilitating more focused action items.

4. Action Items Should Have Intent

Unclear Action Items are worse than useless. One trick is to ensure a verb is the first word of every Action Item. By definition, every action includes a verb, but sometimes the verb is glossed-over or shorthanded in the retro. Everyone in the room understands what’s meant, but afterwards that may no longer be the case. Make sure that Action Items remain actionable when viewed later.

5. Action Items Should Be Falsifiable

Be sure to frame Action Items in terms that can be assessed as “done” or not. “Refactor more” isn’t useful a useful task, because there’s no way to meaningfully tell whether it’s done. “Improve the User model’s Code Climate grade from an F to a D” is actionable, and lets the team take small, achievable steps towards improvement. Also: use Code Climate, Errplane, New Relic, Airbrake or other instrumentation services to help put objective measures on code quality, performance, etc.

6. Action Items Need a Single Responsible Party

Not two people. Not “team” or “all”. One person. When an action item involves the whole team, find a volunteer to be the cop and enforce compliance. If one person isn’t responsible, then no one’s responsible. Addendum: review Action Items. Print them up and put them on the team stand-up board. Cross them off as completed. Review the list at the next retro.

7. What Happens In Retro, Stays In Retro

The retro should be a safe place. Active members of the team should the be ones in the room; sometimes it’s helpful to include stakeholders that aren’t present for most of the week (but that’s a judgement call). Action Items may be displayed publicly, but it’s preferable to only share the raw notes with the people present.

These practices aren’t laws chiseled in stone; they’re hacks and ideas borne of observations of patterns and anti-patterns witnessed in many, many retros. Do you agree? Disagree? Have juicy, anonymized stories supporting or contradicting? Let us know (and share your best retro stories) in the comments.

The Idea Board Technique

A typical Agile Inception ends with a fully fleshed-out backlog for the next few iterations, and some farther-off, coarse-grained, Epic-level ideas written on index cards. What to do with them? Some teams clip them together in a deck of cards that gathers dust and is rarely seen again. I prefer to externalize them on a foamcore board in a riff on a technique Thoughtworks calls an “Idea Board” or “Idea Backlog”.

Making the Idea Board

This is basically an Epic-level reverse-Kanban board that will work in concert with Pivotal Tracker. Create a few columns: “Now”, “Next”, and “Later”. Generally you’ll have 2-3 cards in the Now column, another 2-3 in the Next Column, and the rest (~20-40) in the Later column. The Idea Backlog can often fit on a half-foamcore board (4ft x 4ft), and serves a few uses:

it externalizes future epics so everyone 1) is reminded they exist, and 2) can see their relative priority

it gives Stakeholders a place to park long-term ideas, and feel that their contributions are included

it gives a big-picture view that tactical what-are-we-working-on-this-week systems have trouble displaying succinctly. This is great for strategic-level Release Planning meetings that I like to try to have every 3 or 4 weeks.

On a recent project, we had a bit of Priority Whiplash: every week, we’d go into an Iteration Planning Meeting (IPM) on Monday and agree on priorities. By Friday, someone on the team would say “Why’re we working on this?! What about that other thing?!”. We’d mention the agreed-upon priorities from a few days earlier, but inevitably someone would shake their head and say “I never agreed to that!”.

Idea Board to the Rescue!

We started using the Idea Board and bringing it to planning meetings. Having a tangible representation of the plan helped a lot. “Remember on Monday when we moved the Foo feature set into the Parking Lot to make room for the Bar feature set? I swear no one moved the cards since the last time we looked at this.” This helped a lot. It also really helped that when someone would say “I had a great idea! Let’s make a Baz feature!”, we could write “Baz” on an index card and stick it on the board. It may live in the parking lot for a while, but its visible and everyone is comfortable that we’re prioritizing the feature (rather than forgetting about it).

Some say a big drawback to a strategic paper-based system like the Idea Board is that over time, it falls out of sync with a tactical digital system like Pivotal Tracker. I think this is more a feature than a bug: when the Idea Board has one or two epics that are out of sync with reality it’s no big deal. When the whole board is a big lie, that’s a signal to the whole team that it’s time for everyone to re-asses the alignment between tactical steps and strategic goals: it’s time for a Release Planning meeting.

Writing Well-Formed User Stories

Convention Over Configuration is one of core principles of the Rails approach to software development, and delivers enormous value.

Convention Over Configuration – means that Rails makes assumptions about what you want to do and how you’re going to do it, rather than requiring you to specify every little thing…

Oddly, we tend not to apply the same perspective to project planning: on almost every project, the team re-invents the wheel of “how should we write and format our stories?”. I’ve worked closely with the Product team on about a dozen projects in the past few years, and rigorous story-writing is one of the most common areas for low-cost, high-gain improvement. I encourage every team to adopt (or at least consider) these techniques.

Write every story in Gherkin. I don’t care whether or not you use cucumber: use Gherkin. Which is to say, every story should be in “Given / When / Then” form. This is the cheapest and easiest way to apply Convention Over Configuration to your user stories, and can have a HUGE benefit for your team.

Scenario: User adds item to cart
Given I'm a logged-in User
When I go to the Item page
And I click "Add item to cart"
Then the quantity of items in my cart should go up
And my subtotal should increment
And the warehouse inventory should decrement

Every feature story should include an “As a / I want to / Because…” block, which illustrates the motivation behind a story. Compelling the product team to specify the motivation behind a story help illuminate what exactly the requirement is, as well as providing guidance to the developers. Some people prefer “So That…” instead of “Because“, but in most cases “Because” helps drive out motivation—the Final Cause—whereas “So that” may only drive out the Effective Cause, which is less useful for understanding the story. (Thanks to Sam Coward for this insight.)

Feature: Shopping Cart
As a Shopper
I want to put items in my shopping cart
Because I want to manage items before I check out

Every story title should include the word “should”. NEVER use the word “can”, which camouflages desired behavior. E.g. It’s unclear whether the story “User can delete comment” is a feature or a bug. “User should be able to delete comment” or “User should not be able to delete comment” are much clearer: the former is a feature, the latter a bug. Don’t make me guess.

When a story feels a little fishy, check that these bases are covered. If any are missing, fix then before you do anything else. The answer will often be driven out in the process of working the story into Well Formed shape.

Benefits

Well Formed stories truly drive out the feature from the user’s perspective; this catches 80% of weird edge cases while the whole team is together, in context, and in planning mode, instead of having to interrupt-drive the PM. Well Formed stories make it impossible to camouflage large stories as small stories by elision. Because the story has to be written out step-by-step, all the complexity might otherwise be hidden is forced out into the open. And when you find yourself with conditionals or switches? That’s a new scenario! Now all stories are forced into roughly the same size. Another side-effect is that once one story ~= one scenario, the amount of work to be done can be roughly gauged spatially, by looking at how much of your wall is covered by index cards. For bonus points, use the story title as your git commit, e.g. the story “User should be able to recommend a product” becomes the git commit “User is able to recommend a product”, and your git log tells the narrative of your project.

How did this start?

Once apon a time, J (the anchor) made N (a very bright, technical Product Manager) write stories in Gherkin. Most stories weren’t 100% ready to be pasted into cucumber, but it usually didn’t take too much work to get them there. The team would discuss in IPM, and then devs could copy-and-paste stories right into Cucumber. This doesn’t work for every PM, but even in the worst case, teams with less than tech-savvy PMs see real benefits from writing their stories at the right level of granularity. Once I was exposed to a team where we wrote Gherkin all the time, anything else felt like broken process.

UPDATE: To be clear, the opinions in this article are my own, and do not reflect anything close to consensus or standard practice on the part of Pivotal. Some Pivots will agree with this position, while many others will not.

UPDATE 3/17: Added a brief introduction elaborating on how Well-Formed Stories help bring principles of Convention Over Configuration to story-writing.