agile requirements

10 Ideas to Make Backlog Refinement Rock

//

Before we go through the ten ideas, it’s important to take note of two really important things — backlog refinement is a team sport and backlog refinement is continuous — not just one session every couple weeks. So although most of the ideas are focused on the backlog refinement session, the intent is to introduce ways that we can increase participation, make it easier to facilitate, and hopefully, greatly improve shared understanding.

  1. Be Prepared. Probably the most critical part of making any refinement session successful is being prepared. What does this mean, well maybe a checklist is in order:
    • Identify the top-x stories that are not “ready” and need refinement. Ideally, your backlog is ranked, and it’s the next items on the list.
    • Identify the questions for the team and invited subject matter experts.
    • Prepare any artifacts that will help the conversation around the stories (e.g., designs, user feedback, 3rd party specifications, etc.).
    • Send out the agenda with the list of stories to be covered and identify the preparation steps for the attendees.
    • Make sure that if you have remote people that you have identified the technologies that you will use (e.g., web meeting software, full-duplex phone, online brainstorming tool, etc.) and you’ve tested these out.
    • If there’s someone new or the meeting will be largely remote, plan to either start early or use the first few minutes to get everyone connected — set this expectation ahead of time.
    • Identify and confirm the facilitator and the approach for capturing notes and observations. Let’s not have all the great ideas and things we learn to escape into the ether.
  2. Design Storm. A Design Storm is a type of workshop that is usually associated with human-centered design and or design thinking where participants are asked to create a low-fidelity concept around an idea or problem a group is trying to solve. For a Backlog Refinement session, you can use this approach to get people who might not normally speak up, to get engaged in the process. Generally, participants will uncover great ideas, and discussions will ensue around complexity or “de-complexifying” the backlog item(s).
     
  3. Lo-fi Prototype. Create a low fidelity prototype and pass it around the room or have multiples created. Something as simple as sketches of the screen(s) and when someone “clicks” a button or enters a field, you can show another sketch or discuss content. You don’t have to be an artist or use some amazing (a.k.a. complex) UX mocking tool. Just use post-its and or normal letter (or A4) paper. When you use this approach, encourage folks to be critical and question everything, even if it’s an area where you tried to mark out a mistake. If you are wondering just what a low-fidelity prototype is, check out this article by Laura Busche.
     
  4. Oblique Strategies. Oblique strategies are a set of statements that are meant to create a challenging constraint to help increase creativity through lateral thinking. Okay, this one may seem a little odd for a backlog refinement session, but I’ve been witness to many sessions where the ideas to solve the user problems are mundane and more of the same — often being offered by the same 1-2 people in the room, over, and over, and over again. Oblique strategies can help the group try something new. Do a quick search on the app stores, and you’ll find an app that has oblique strategies listed. NOTE – some oblique strategies are to help musicians and might not make sense — go to the next one.
     
  5. G-W-T. Given-When-Then (a.k.a., Gherkin) is the product of Behavior-Driven development. GWT is an approach where as a team, we can use a structured language to talk about how a user [or system] may interact with a tool or piece of software to achieve their desired outcome. If you’ve never used GWT, you’ll find the structure to help drive some conversations and give clarity to the behavior the system without dictating the solution.
     
  6. SQUID. This acronym stands for Sequential Question and Insight Diagram. SQUID is a great approach to allow the group to ask questions and record the answers. It can be done interactively with the facilitator(s) capturing items, or ideally, there are a series of brainstorm moments where the team writes questions, and the knowing team member poses answers. The process repeats until the team has clarity for the backlog item. See the GameStorming.com website for how to use this approach.
     
  7. Apply Lean Coffee. If you’ve never heard of Lean Coffee, it’s an approach to facilitating an open session of people. Generally based on a context, Lean Coffee provides a means by which to structure discussions through the use of a personal kanban board and time boxing (see leancoffee.org for more information). For a backlog refinement session, instead of brainstorming and dot-voting topics — use the backlog items to be discussed. Applying the Lean Coffee structure does two things — (1) focuses the discussion on one item at a time and (2) it helps keep the conversation moving instead of getting stuck on one item for too long. When I’ve used this question in the past, the question around extending the time box was “Can we estimate this one yet? If not, do we keep talking? Or, does it need to go back with the PO for more discovery?”
     
  8. Story-walk. One thing that brain-science has made clear, our noodles are more engaged and work better when we move, and there’s some variety. A story walk is simple, print out the story details as it’s known today — make it big, so it’s easily readable. Give each person a pad of sticky notes and a marker. Ask them to walk around writing and posting Questions (?), Assumptions (!), Actions (*) and Ideas ($). Make sure they use symbols that make it clear what type of post they are submitting. Do this for 20 minutes, and then ask the team to re-walk the stories — this time clarifying and grouping similar items. After ten more minutes, focus on the questions, and get them answered. Hopefully, by the end of the session, you can do some quick affinity estimation or white-elephant sizing. A similar exercise as the story walk is doing a story workstation, where you set-up multiple tables with handouts containing details about each story. The ask is the same, but instead, the participants are moving table-to-table.
     
  9. Triad-up (a.k.a., Three Amigos). Have three people take a backlog item and gain an understanding of it. The three people should be made up of one with business knowledge, another focused on the question of “how to test?”, and another person focused on the question of “how to build?” These three amigos should do their best to get the backlog item to a point where they believe the team should be able to estimate it together. Get the room into triads, divvy up the backlog items, and give them a time box to discuss the backlog items. Leave 15-20 minutes for shared discussion and estimation at the end. To learn more about the Three Amigos (in context of agile software development) check out this article by George Dinwiddie.
     
  10. Re-baseline Understanding of Refinement. One thing we often do as humans is that we often extend our level of understanding what we believe others know about a topic. Well, if a team hasn’t been doing something for very long or that something they are doing hasn’t been very effective, then it’s probably time to practice something new. All that said, take the time to discuss the concept of refinement, the team’s role in refinement, how a refinement session should work, and the desired outcomes.
     

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

/

[su_note note_color=”#fdfdce”]WARNING: Shameless plug for my session at Agile2014 ahead.[/su_note]

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:

Documentation Formula

Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

Twelve Awesome Interactive Facilitation Techniques for Agile Teams

///

If you work with a team, and possibly, you are the Scrum Master or Lead or Product Owner, or just a Team Member trying to guide a conversation — then these interactive facilitation techniques are for you. But before we move on, let’s first get it out there that we may call these “Interactive Facilitation Techniques”, but they are really games. More specifically, games that help us at work. Using games — I mean interactive facilitation techniques — help us to effectively and easily facilitate discussions. Using these games to helps to drive good team behaviors (Blunt 1993) including cooperation, clarifying, inspiring, risk taking, harmonizing, and process checking. All the while, helping to overcome the destructive team behaviors of dominating, rushing, withdrawing, digressing, discounting, and blocking. That all being said, let’s get to it. The following list of games are those that I’ve personally used with teams that I see work really well and are easy to adapt. I’ve taken the liberty to group them by the team meetings where they make the most sense; however, as I previously said — they are easy to adapt and can be used for almost any activity.

General Brainstorming

Affinity Mapping – An oldie, but a goodie — this great way to collect, organize, and rationalize ideas — even large amounts of ideas. I’ve used this to help understand the objectives of meeting attendees and get everyone on the some page. Here’s a great a time-lapse video of a team using Affinity mapping to sort 500 pieces of customer feedback…

Dot Voting – Dot voting is a simple way to get a group of people to form consensus. This technique let’s everyone have a voice and it’s a quick and easy way to rank things. By the way, here’s a cool and FREE tool to do this with distributed teams … DotStorming.com

Pre-mortem – First off, let’s remember that words mean things and mortem is related to death. So I equate doing a pre-mortem to death planning including making your bucket list, understanding what things you should do to be health, and things to do to stay safe. The pre-mortem is a great risk management technique.

Discovery

Product Box

Product Box – Also known as Vision Box, this is a great way to discover what customers think, a way to uncover expectations, and ultimately share – or gain a shared understanding of the product or project or release. I find the product box to be a great exercise for Release Planning and project chartering.

My Worst Nightmare – This is a great way to get into heads of the team and learn from their experiences, anxieties, and expectations. An easy way to express yourself, you use pictures. They say a picture is worth a thousand words and it’s true. I use this exercise to prime the pump on understanding objectives.

Spider Web – Another game from Innovation Games, Spider Web is a form of context diagramming, but it’s no the run-of-the-mill context diagramming. First, everyone get’s to draw, second — use pictures, and finally, no rules — lines can go from one item to another. You’ll find this a great game to understand information flows between people, systems, and organizations.

Requirements

Staple Yourself to Something – Have you ever found that getting started is the hardest thing to do? Well, this is the perfect game for you. This game involves mapping out processes, it helps to quickly get everyone on the same page as to how something should work. It helps with knowledge exchange, establishing process flow, and establishing a shared understanding.

Empathy Mapping – Establishing personas is a key activity at helping to understand our customers or the users of the systems we are building. This technique is a fast-and-easy way to do understand our users as a team. Even if you already understand your personas, let the team do this exercise and see what they discover.

Buy a Feature – Have you’ve ever been frustrated with stakeholders not being able to make prioritization decisions? Buy a Feature is an awesome way to help drive the discussions around prioritization. You may not land on the final ranking, but you will gain some awesome insight into what is important and where people are willing to negotiate.

White Elephant Sizing – This is the only way to estimate stories. Okay, not the only way, but it’s a good way. This game is a spin on the White Elephant gift exchange we do after the holidays. The values of this game are conversations and shared experiences of all the players. If you want to find a fast way to estimate, try this.

Retrospectives

Sailboat

Sailboat and 4Ls – I’ve talked about both of these games before, and I play them regularly to help evaluate coaching sessions. I encourage folks to mix it up all the time with regards to retrospectives, and these two games are great ways to do it.

Learning Matrix – This one is from Diana Larson and Esther Derby’s Agile Retrospectives book. What I really like about it is that you find things to improve upon based on looking at what you are doing right. You review where things are going well and look at how applying what you are doing well to this things that are going wrong.