Agile35 cards which will improve your backlog refinement process and engage every team member

• Agile35 cards which will improve your backlog refinement process and engage every team member

Introducing this playing card game to my team enabled us to achieve more than we could ever imagine. The game is supposed to be streamlined backlog refinement and improved understanding of what needs to be done.

Imagine a conference room and backlog refinement meeting is being held in it. Mike is scrolling his phone, Jane is compiling her shopping list, Dave pretends to be interested while he is thinking about the muffins waiting for him after lunch. Ana and Rick are facilitating the meeting, as always, talking about the stuff that has to be done in the next sprint. These guys have been repeating this process for so long that the meeting turned into a boring routine, and nobody seems to care about the backlog refinement. If you change the names and verbs in the previous paragraph, it is likely that this pattern can be applied to your team as well. Nobody should be blamed for such situation, the fact is that every recurring action (meeting) tends to get boring over a period of time.

The solution?

This situation happened to my team as well so we came up with a solution. The solution involves 35 playing cards, and a stopwatch.

How does it work?

Schedule a meeting and get your team in the same room. Shuffle your card deck and deal the cards to each team member until there are no cards left in your hand. You are now ready to start your new backlog refinement process. Cards are ordered and numbered from 1 to 35. So the game starts with the team member who is holding card number 1, then the next team member with card number 2 and so on… It is important that each card-holder fulfills the task written on the card so that everybody takes part in the process.

Benefits?

We recognized two main benefits from this process:

1. Everybody takes part in the refinement process and provides a high-quality output. Usually, the most creative solutions and suggestions come from the quietest team member. Introverts are often most creative, they just need a spark to kick off.
2. Cards are a more interesting substitution to checklist. Each card makes you ask all the questions related to refinement process. Even the obvious ones. Asking obvious questions often sparks a healthy discussion and yields different perspective and better results.

Card deck

Card design is still in progress, but here is the concept. Shuffle and deal. Depending on the team size, each team member will get 3–5 cards. Each card represents a role in the refinement process, so the team member that gets the role will have to act according to the instructions written on each card.

1. Time Tracker

It should be clear that the refinement should not answer all the questions. Rather it should improve the knowledge about the topic. Therefore, the discussion should not last for too long. This is why it is good that each discussion is time-boxed. This gives you the sense of urgency and it is more likely that the decisions will be made faster. Another benefit is that you will cover all the user stories which are pending in the backlog, not just the one whose discussion goes off the track. This is why somebody should be assigned to a Time Tracker role.

2. ABC

Always Be Capturing. Meeting notes are important. They will jog your memory after three days when you totally forget what have you been talking about. So somebody has to have pen and paper to write things down. Notes, questions, ideas, doodles, everything is good and important and valuable. This will prevent things falling down the cracks. These notes will have great value after the meeting when things should be formalized in a form of Acceptance Test or User Story description. This will be addressed in some of the following cards.

3. Joker

Besides the duration of the discussion, which we addressed with time-boxing, another thing that could lead to divergence is off-topic discussion or discussion about the trivial stuff. Joker should detect such situations and if things are going south, card-holder has the right to stop the discussion. Actually, he/she has the obligation to do so. In a nutshell, Joker should prevent from happening and keep the discussion on the right track.

4. Point Bank

Assuming your team has been working together for a while, you have a record of your team’s velocity. This is a relative number which is supposed to indicate how much work you can deliver in a sprint. The idea behind this card is that somebody should keep track of the estimations given for each story. If you agree on adding the User Story to the sprint, the estimation for it should be subtracted from team’s velocity. As you add more stories, you will burn your velocity down. At this point, you should draw a line for the following sprint, since it is likely that your team’s capacity is full.

5. Big Picture

We’ve assigned these formal roles (time tracker, note taker, etc), now’s the time to start the real discussion. Opening act for each User Story should be a high-level overview of the feature which needs to be built. So this should be a brief introduction to what needs to be created. Opening act is important because everybody needs a little context to kick-start the discussion and get the ideas going. So don’t just jet go into details about the User Story, just give a short overview of what needs to be done.

6. Goal Compliance

Every team or a company have their goal in mind. It can be a goal for this quarter, this year or a general goal derived out of your core values. So before you move on, you should ask yourself if this feature is in line with your goals. If it is, you’re good to go. If not, you should discuss if the feature is really necessary and what kind of value does it bring to the team or the company. Sometimes it can be once-off payment milestone, side project etc., but most of the time, everything you do should be aligned with your goals.

7. Why?

The purpose of refinement meeting is to remove uncertainties related to the work to be done. The first and foremost uncertainty is the purpose uncertainty. Why would you ever want to create what you’re about to create? As - always start with why. Ask yourself why do you want to build that feature. What is the core value that comes with it? If you haven’t already, watch . He explains this point better than anyone in the world, ever. Seriously, truly inspiring video.

8. What?

The second uncertainty is end uncertainty. What do we need to build? Start at the end and try visualizing the end product and how the users will benefit from it. This will give you a goal, and if you visualize it in enough detail and approach it with passion, this will be your driver when entropy kicks in and starts messing with your initial plans. If every team member is aligned with the end goal, they will be better at solving problems, because they know where they need to be at the end.

9. How?

The third common uncertainty is means uncertainty. How can we build it? The ideas are fine, ideas are the fuel, but when it comes to actually building the things you visualized in your head, that tends to be really challenging. So you will have to ask the team how can it be built. Or can it even be built? This can affect your initial plan and can force you to pivot, so it is important that you know it upfront. Since you’re probably surrounded by great engineers, most of the time “how” will not be the problem.

10. Box

Now that you’ve removed uncertainties, the shape of the final product starts appearing. You can ask the team what’s on the box. How would you label this product and how will it be called or branded? This stage will help you verify the assumptions made by the card #8-what?. This will remind the team what are we actually building, and put a seed in their minds. Visualizing the package will help everyone in consolidating the picture of the final product, and set a course for the journey toward that goal.

11. Fast forward

Again, imagine that the product is finished just as you planned. How are you going to market it? What will you go-to-market strategy be? How are you going to present your product to the user? Who is the user anyway? Finishing a product is not the end of the road. Rather than that, the party has just begun. You will have to persuade the user that your product is just what they need. So you better be ready for that, because it is one of the most important stages in the process of product adoption.

12. Awesomeness

You created your pitch for the user, but take a moment and make sure that the benefits that you are promising are actually touching the pain points of your users. How does the product or feature make the user awesome? Which super-power are you handing them with your product? What will they love about it? This is important for product adoption because early adopters will pick it up anyway, but to to the next market segment (early majority) you will have to deliver real value. So what is the real value of your product?

13. Fail

Lucky number 13. I didn’t plan to assign a failure topic to the card number 13, but somehow it worked itself out this way. Anyway, pretty nice coincidence. So far you were thinking optimistic and positive, which I always support. But sometimes it is good to take a moment and think about what could go wrong in your plan. As a result, you will predict potential failure in the early stage of the development, which is always better than shattering the whole plan after weeks or months invested in the solution which failed one way or another.

14. Remix

Some of these cards are inspired by Jake Knapp’s book . This book really changed my point of view when it comes to software development process. Great read, highly recommend it. Anyways, remix and improve is one of the techniques from this book. It says that you should think about existing solutions to a similar problem, use the pattern and adapt it to your problem and improve it. I’m not a fan of reasoning by analogy, but unless your trying to innovate radically, this is usually the shortcut to the best solution. Somebody spent a lot of time figuring a similar solution, so you should work smart and use that.

15. (16,17) Sketch

Talk is cheap, start sketching. The best way to get everybody on the same page is to draw things on the whiteboard or a piece of paper. By now, you should have enough context to be able to sketch several solutions. This card is intentionally repeated three times so that more than one person has a chance to express their creativity. More solutions mean more options and potentially better final result. You can also try “crazy 8s” technique from Design Sprint book. Put your ideas on the paper and they will come to life.

18. Storyboard

Previously, you’ve created several sketches for your solution. Now is a good time to think about the steps which user has to take to discover your solution. Start at the very beginning — user opens the browser, or opens your app. What are the steps, clicks or taps which needs to be performed in order to get to the desired outcome? How many steps are there to be taken? The storyboard will help you get the picture of how complicated is for the user to get to the point where he wants to be. This way, you will identify missing steps or the one that is obsolete.

19. Test

Planning your testing scenarios is as important as creating a good design. To ensure you have a good quality release, your solution has to be tested and validated against as many real-life scenarios as possible. So now is the time to identify those scenarios and write them down. This is also a very valuable input for the developers because they will have to cover all these scenarios during the development process. So think about the scenarios, possible outcomes, data required, the hardware required, etc. Be sure that this step will pay off later.

20. (21,22) AT

So far, you’ve answered most of the questions and uncertainties. Now you can write some acceptance tests for this user story. Acceptance tests might be in a familiar form of “As a” ___ “I want to” ___ “in order to” ___. Or whatever form fits your needs. But it is important that you write the requirements. You can think of this as a statement that needs to be true after you’ve finished your development. This statement should be a quick reminder of what you plan to build and deliver. Again, there is more than one card, since it is good that more people give their perspective. And since everybody has been involved from the start, the statements should be fairly similar, or you still have some misunderstanding on your team.

23. Estimation

You have a clear picture of what needs to be built. You came up with the idea how you’re going to build it, you know the tools and technology. Now, you should bid your estimation points. The estimation is relative and varies between teams, but it is important that you use consistent estimation framework (i.e. Fibonacci numbers). This will help you to understand the scale of the work, and to check if you have enough capacity left for the following sprint.

24. Mock-up

To put a cherry on the top, invest some time to create a Mock-up of the solution. This will be pretty much the same as your sketches but in a digital form. You should follow the Goldilocks quality - not too detailed not too crude. You can use any tool you’re familiar with as long as you capture all the things you mentioned during this discussion. These mock-ups will be useful for the team since they will guide UI development. Also, the images will be a good reminder of your goal. Note that this can be done after the meeting since it takes some time…

25. 3 amigos

There’s a pile of notes and papers on the table. There are notes, sketches, mock-ups, acceptance tests, questions. Somebody has to take care that all these inputs are stored in one place and organized so that you can take a peek if you ever need a reminder or information about the feature. The team member who has this card can pick two more team members to help him with this. After the meeting is done, they will do the tidying-up and everybody else will have a smile on the face because they didn’t get to do this.

26. Dependency

If you work in a relatively large company, with more teams, the work is probably distributed between a couple of teams. If that is the case, you should ask yourself if you have some dependencies between the teams. If so, you will have to make sure the work is synchronized, and everything will be done in a chronological order and with the least possible downtime due to race conditions between the teams. Hopefully, you still enjoy working in small companies, and you can skip this card.

27. 20:80

Most of the time, 20% of the feature can cover 80% of the requirement. You should always ask yourself if this is applicable to your product. If you could spend only 20% of your money and provide 80% of the value, that’s a pretty good deal. Usually, every each of us tends to over-engineer things. Sometimes to challenge ourselves or just to show off a little bit. But in reality, there is no need for that. Beauty is in simplicity.

28. Milestone

Every project has a deadline. It can be a release date, project due date, payment milestone, dependency due date, etc. In any case, time is not your friend. So that being said, you should make sure that the plan you’ve just created can be executed in a timely fashion. You wouldn’t like to miss the payment milestone, would you? After the plan has been created, sometimes you can be so excited and energized that you forget to think about the due date. This should be a reminder.

29. Ready?

If your team has a definition of ready, now is the time to revisit that check-list. Check if everything is understood, and clear. Even confidence voting can be performed at this stage. This will give you the sense of general readiness of the feature or the product. This card is just a trigger which will make everybody comfortable with moving on. Please disregard the text in the image which says Definition of Done, you’re not done yet :) The previous set of cards should be iterated for each feature your team plans to implement. The following six cards are related to the entire sprint.

30. Challenger

Great job, you managed to improve your backlog and general understanding of the features which needs to be implemented. You probably feel energized and positive about the outcome and final product, which is great. But somebody has to be a party-pooper. This is a role of the challenger. He/she needs to take a moment and ask the team if they are sure if they can accomplish all the work they just committed to. Most of the time the answer is positive, but it doesn’t hurt to double-check.

31. What’s next?

If somebody feels like they have the capacity for more work, you could take a peek at some more features from your backlog. Even if you don’t have the capacity, it’s a good practice to take a look at the features which are waiting in the backlog. You could stumble on some interesting feature that is related to the one you are developing now, and it might change your perspective, or change the scope of the work planned for the sprint in order to set the stage for the features yet to come.

32. More?

Once you had a glimpse at the backlog as if you could take some more work in the sprint. Probably not, but just ask. Maybe somebody feels like working overtime. Just kidding.

33. Prioritize

This is usually the task for the product owner, but it is good to do it together with the team. Place the most important features at the top of your backlog, and the least important at the bottom. Give a business context to each reorder action, so that the team gets the sense of the . When the team understands the business side of it, it is easier for them to set their goal and achieve the expectations.

34. Goal

Speaking of the goal… With the previous card, you’ve briefly touched every feature or user story. Is there a feature which dominates the backlog for this sprint. If so, that might be the goal. Anyways, the team should come up with the goal, since they will benefit from it the most. As I mentioned before, the goal will lead them and will give them guidance as the sprint roles out. Write it down on a whiteboard and keep it there until the sprint is finished.

35. Relax

Most of us tend to over-commit. This card should remind you of that fact and should help you relax for a little bit. If it is possible, as for some slack time, and reduce your individual scope. That extra time you’ll get will help you deliver the feature with higher quality since you won’t work under pressure. I insisted on calling this game a solution. But in fact it’s just a way of breaking the loop of boredom. You may find some of the cards useless or meaningless, but feel free to remix and improve. The important thing here is that you have to innovate and make things interesting in order to move them forward. I would love to hear your thoughts about the game, experiences with your team and new ideas for backlog refinement, so please do put them in a comment below. Every feedback is highly appreciated.

Have fun, nourish your creativity, make it happen!

P.S. Give it a clap or two if you'd like to have this card deck! :)

Want to learn more?

Turn your idea into a successful business today. This book offers you a comprehensive guide through the entire process of creating a successful business. It is designed to make your start much easier by laying out the entire for you. The entire process is boiled down to its essentials, making the steps simple and easy to understand. If you follow the formula which I reveal in this book, it’s very possible you can make a living by turning an .

Get your free book summary by clicking on the image below: