Table of Contents

• Purpose of This Book
• Some Practical Stuff
• Experiment Driven Change
• Door Calendar
• Doing Dots
• Bugs for Breakfast
• Communication Protocol
• Tasty Timeboxes
• Where Does The Time Go?
• Event Log
• Resilience Map
• Recruitment Retrospectives
• Appreciation Flowers
• Value Poker
• In-Line Definition of Done
• Not Now Backlog
• Visualised Flow

Purpose of This Book

I have been helping teams and organisations to adopt Agile ways of working for close to 10 years now, usually as a Scrum Master or Agile Coach. During this time, I have had the privilege of working with a lot of great teams. Being exposed to a lot of different environments has been a brilliant learning experience, as each organisation is unique and therefore forces you to try new things and approaches in your efforts to support change. This book is about sharing the toolkit I have developed during this time.

Many of these tools were developed incrementally within teams I worked with, some literally taking years and exposure to a variety of organisations to reach their current state.

Of course Agile is more a way of thinking than it is a particular tool or practice, but sometimes you simply have a problem you need to solve and getting a starting point will make a big difference. That is the purpose of this book.

Most of these tools are very simple and can be implemented in less time than it takes to read about them, but beware, the last thing you want to do is take all the things in this book and start doing them tomorrow. Some things will only help in a particular context, and everything requires that all individuals affected are on board with any change.

The first chapter in this book is about what I call “Experiment Driven Change”; you should consider this as the basis for the book and apply its principles when trying any of the other tools. This way of thinking has been instrumental to my career and has driven the creation of all the things that come after it in the book.

Some Practical Stuff

Credit

Not all of these tools were originally created by me, and basically all of them were iterated by a group of people. The credit section at the end of each chapter is to provide appreciation to others involved.

Assumptions

This book assumes basic knowledge of Agile practices, as well as experience working in an agile team. This should not be your first book on the subject.

Images

High resolution copies of all images can be found here: http://links.rebelalliance.se/actionable-agile-tools

Open Source

This book is an open source project, available at: https://github.com/Zebra003/actionable-agile-tools

This book is licensed under the Creative Commons “Attribution-ShareAlike 3.0 Unported” license. http://creativecommons.org/licenses/by-sa/3.0/deed.en_US

Meaning you can modify and reuse the contents in anyway (even commercially) as long are you give credit, and allow others to do that same with your work.

Experiment Driven Change

The ability to continuously improve the way we work is central to all Agile teams and organisations. Most teams use Retrospectives or similar meetings, but far too often those meetings follow an unproductive pattern.

• Put a bunch of notes up on the board.
• Discuss them.
• Create a list of 10-15 problems.
• Agree those need to be improved.
• Give that list to the Scrum Master or mail them to a manager.
• Come back in a few weeks and have the same discussion again.

They do this for a few months or years until finally someone in the team has the courage to say “Why do we even do this? Nothing changes as a result.”

If you are following this pattern, you are missing out on the value of Retrospectives. The most valuable thing about Retrospectives is the frequency at which we have them. This allows us to do things differently than we would in something like a project post mortem.

Consider moving to Experiment Driven Change.

Focus

Since we are meeting with such frequency, we don’t have to treat this as our only opportunity to identify everything that is wrong in our organisation. Instead, we can focus on only one thing and try to have an impact on that. This has an important mental effect, because focusing on all the problems we have in the world is exhausting and overwhelming. By focusing on one thing, we start to feel like the issues are more manageable.

Experiment

But the biggest upside to meeting so frequently to discuss improvements is the approach we can take to those improvements. We don’t need to find the perfect solution to the issue we are discussing, we don’t need to form committees and build consensus across our organisation. As a matter of fact, we don’t even need to know our solution will work at all.

Because we are working in such small increments, the only thing we need to come up with at a Retrospective is something to try out for the next few weeks: an experiment.

Because we are only going to try the experiment for a limited amount of time, any negative impact is controlled by the fact that when we meet again we will decide not to do it anymore.

And if it happens to make things better, well, now we are on our way!

The focus of a Retrospective is not to fix all our problems overnight; the only thing we are aiming for is to make the next few weeks slightly better than the ones before. Gradually as more of these experiments work we will start to feel their cumulative impact.

Output

Here is a very simple model I use to attempt to arrive at usable experiments.

Symptom

This is the “one thing” we have chosen to focus on. I always like to proceed from the premise that this thing is merely a symptom of an underlying issue.

You can arrive at this “one thing” in a variety of ways; you can look at any Retrospective format and it should provide a facility to arrive at this.

Root Cause

Rather than simply launching into solution mode, we want to spend some time trying to arrive at what could actually be causing this, the root cause. Many tools exist for this portion of the discussion; in the example a tool called “5 Whys” was used. But the most important thing is that we are open, honest, and dig a bit deeper.

Experiment

This is where we decided upon specific actionable things that we would do to attempt to address this during the upcoming Sprint. While we would like consensus from the whole group, we don’t need it for the experiment, we merely need everyone to be willing to try this out and see if it works.

Success Criteria

How will we know this change has worked?

We don’t want to simply know that we have done it, that doesn’t insure it’s an actual improvement, just that we did what we said we would do. It’s nice to have something measurable here, but that doesn’t mean we need complex metrics, a measurement can be as simple as “80% of the team agree this was a successful experiment”.

Follow up

How long will we try this before we evaluate its success?

Driver

The driver is not responsible to do all the work themselves; they are responsible for reminding us as a team to live up to the commitments we have made to ourselves. It’s very easy to forget these things when our heads are back down in the code.

Repeat

And that’s it!

Do I know this change will work? No.

Do you know what won’t work? Doing nothing…

Tips

• Learn more about Retrospectives to make best use of this tool.
• Vary the method used to arrive at “the one thing” we focus on.
• Vary the tool used during the discussions of root causes.
• Timebox each part of this tool.
• Spend more time on root cause than actually devising the experiments, because that’s where all the value is.
• Use a Retrospective to focus specifically on this tool to see if there are any improvements you can make to it or your use of it.
• Never volunteer someone else to act as driver.
• Do not always have the Scrum Master act as the driver, teams need to feel responsible for their own improvement.

Door Calendar

So named because it turns out the door is often a convenient place to put it, at least it has been for me three times.

Sometimes with your head down focusing on delivering value it can be easy to lose sight of what’s coming up. Or maybe you have certain events that happens at irregular intervals, such as holidays or company events. Or maybe the Sprint Review sneaks up on you every time!

This is where the Door Calendar comes in.

The Door Calendar is a simple information radiator that helps you see when events are approaching so you’re not surprised by them. A picture really illustrates the concept best, so I’ll start with that.

The calendar is constructed using tape, a marker and Post-its.
The top row includes days of the week.
Each cell on the calendar is large enough to hold a Post-it note.
These notes are added with some small text to indicate what the event is.
Another note is used to indicate where today is.
You can have week numbers (Swedes love week numbers) or dates along one side.
During your daily meeting the today note is moved and new events are added.
At the start of each week everything is moved up one row so we can see a bit further.

Updating it as a team makes sure things don’t sneak up on anyone as they see the events approaching, but it also works brilliantly for starting discussions.

Tips

• Get in the habit of having everyone look when you move the today marker, it only takes a few seconds and adds a lot of value.
• Use different colour notes to indicate different types of activities like normal cadence meetings, holidays, one off’s, and more extra important events.
• Don’t be shy about putting fun things like outings and team events up there.
• Add dates to the week # column.
• Don’t make it any more complicated than described here, it easily gets cumbersome to update.
  • The first version I created had laminated cards that could be reused and moved to indicate holidays, it was a pain and took WAY too much time for the initial setup.
• Keep the weekends on there, hopefully you never need them, but they also serve to break things up a bit and make it easier to look at.

Doing Dots

Partially done work is a tremendous source of waste in the IT industry. This partially done work usually takes the form of items that never move on your board. You know the ones, the Post-its you don’t even see anymore because they have been on the board long enough that your mental ad filter blocks them out.

These items are a much more serious issue than most people think, because they represent an investment that has not been realised. We have put time and energy into these items but we have not received the intended value from them as they have not been finished. Think about it, even if you put in very little time, just getting the note up on the wall required some planning, discussion, and labour. All these are a cost for value that has never been achieved.

These items are sometimes unimportant and should simply be thrown away, usually because they have been there so long the value has been lost. But more often than we would like these are items that have gotten blocked because of something which is not trivial to resolve. They are easily identified through conversation like:

Or the worst one in my opinion:

I had a team once that had a “customer approval” column on their board, which was absolutely covered in notes. When we decided to follow up these notes, it turned out most of the time the customer didn’t know they were being waited on. One of the customers had actually gone to another supplier because they got fed up with waiting!

By leaving items in a blocked status we are not addressing the underlying issues that allowed them to become blocked in the first place and creating the possibility for future items to become blocked because of the same root cause.

Doing Dots won’t actually fix this issue for you, but it will make it more visible and hopefully a bit harder to ignore.

Every day that an item spends in a stage of our process it gets a dot or tick placed on it. Easy as that! Takes a few seconds every day.

Eventually these items get absolutely covered in dots and we start asking questions of ourselves that we might never have asked otherwise:

At the very least we will have to take notice of the item for the very brief time it requires to add the dot each day so we can’t just move it lower and lower until it eventually falls off and get’s thrown in the trash.

Work in process limits are also made to address this, but it’s possible to have this happen even with limits in place and simply flow around those items.

Tips

• Tally up the dots to provide the cycle time of the whole process.
• Use a different colour for each stage, they can be tallied to provide a cumulative flow diagram.
• Visualise what the blocker is by using other symbols like “?” and “!”.
• Take items with the most ticks to your retrospective and try to find common causes, and of course ways to address them.

Bugs for Breakfast

People often say that quality is essential to the success of Agile teams. But really, they mean that quality is essential in any long running team and we choose to focus on it in Agile teams. But how do you keep quality top of mind? How do you make sure quality issues aren’t being ignored or down prioritised?

You eat Bugs for Breakfast!

We of course want to be moving towards defect free environments and making sure that quality is simply built in, but many teams are not there yet. Bugs for breakfast is built to help along that journey to the defect free utopia we dream of.

Bugs for breakfast is a meeting where the team spends some time together eating breakfast and socialising, but this time is also used to increase our quality focus. During this meeting we take some time to examine whatever indicators of quality we have in the team; this could be error logs from the servers, bug reports from customers, defects found by testers, our issue tracker, or what have you. We then try to find trends and groupings of issues so we can plan to take a bite out of whatever the biggest ones are.

You can then plan to take these things back to your Sprint, make them highest priority on your Kanban board, or simply sit as a team and address some of them right there in the room. The important part here is that you not only look at the quality issues, but use this as a platform to do something about them.

Eventually when your breakfasts have had a big enough impact, the jump to zero defects is a much simpler one. And when people people ask you how it is that you have no bugs you can say:

“Bugs!?! My team eats bugs for breakfast!”

Tips

• Start with an interval of one hour, once a week.
• Have issues printed or on Post-its, instead of in a bug tracker to make grouping a more engaging activity.
• If your company won’t pay for the breakfast, just ask each team member to contribute a small amount to make it happen.
• If you’re a Scrum Master, make this really easy for your team by sorting the breakfast aspect for them.
• Look for things to resolve that have a good ROI, so you get more time to address the next thing.

Communication Protocol

Striking the right balance in communication can be very tricky. In Agile teams we value face-to-face communication because it’s high bandwidth and enables rapid feedback. But within a team communicating everything face-to-face can cause a lot of interruptions, and even tension to break out in the teams.

If you feel you are having trouble striking the right balance, try getting a Communication Protocol in place.

A Retrospective is a great facility for this.

Start with an introduction, explain to the team that you will talk about how and why you communicate, and to decide on your rules of communication.

Remind everyone that all decisions are experiments, so no one needs to feel like they will be locked in by a decision they don’t agree with. We will simply bring it up again and try something else if someone can’t live with a decision long term.

I like to have a quick round table about how people feel communication is working within the team. This helps everyone open up, and gives us an idea if there is a problem and where it might be.

Next an open brainstorming session about in what situations people need to communicate with one another. I just ask people to shout out suggestions, I write them down on individual Post-its and put them up on the whiteboard. This further encourages open discussion, and allows team members to build off each others ideas.

Now we have a list of reasons to communicate, now we need to see how we communicate. Have the team discuss and list as a group the different facilities we have for communication. Some common examples are:

• Face-to-face
• Daily standup
• Team chat
• Email
• Issue tracker
• The board
• Planning
• The Retrospective
• The Review

Then have a brief discussion about the benefits and drawbacks of each of these, write them down separately for future reference.

Use each facility that comes up here as a heading on the whiteboard and ask everyone to start grouping the different circumstances of communication under them. When there is disagreement have a discussion surrounding it. If it can be resolved quickly, great. If not, move them to a “parking lot” until the end of the meeting.

Once you have grouped all the ones people can agree on, move on to the ones that were not trivial to resolve. Allow a short timebox to discuss each one, but if in the end agreement can’t be reached, use a simple voting system (fist of five or dot voting) to decide the initial state and mark that item as disputed. This will make people who didn’t get their way to feel a bit better, and make sure you follow up how well the solution is working.

You now have a Communication Protocol!
You’ll probably want to transfer it to the team room in some way.

The true value of this is in the discussions it spawns, not the actual output. Things like:

Tips

• If you don’t have a team chat, get one, they fill the place between face-to-face and email very well.
• Rephrasing the output into a series of questions and answers makes it easier for new team members to understand.
• When in doubt, choose face-to-face, it’s always the safest option.
• In groups that are quiet, or have extremely dominant personalities, have people list the circumstances as an individual activity.

Tasty Timeboxes

You often find yourself wanting to refer to past sprints or iterations. Maybe you want to communicate to stakeholders when in the past something was released or built, maybe you want to remind the team of a specific situation (“remember how awesome Sprint X was?!?”), or for many other reasons.

People solve this in a variety of ways, the simplest being to number them, some name them after sprint goals and others pick a theme, like gemstones or chemical elements. But I like to take it one step further with a tool I call Tasty Timeboxes!

Tasty Timeboxes work just like a normal naming convention, you start with “A” and iterate through the alphabet. But Tasty Timeboxes take this one step further by using something the whole team likes to eat, baked goods for example. Apple pie, blueberry crumble, cherry cheesecake, devil’s food cake.

At your review meeting, at the end of each Sprint, you not only get to look at the amazing working software you built, and collect valuable feedback, but you get to eat something tasty together with all your stakeholders and teammates! What could be a better moral booster?

The first team I was in who used this we had our customers visit every two weeks for our Sprint Review, you would look at everything and then take a break to eat cake together. So, it also had the added benefit of helping our customer relations, and encouraging informal communication. We even had a tradition for a while of team members baking the things we ate.

Obviously, cakes are not the only option. Cheeses, fruits, ice creams, and candy all work well. The options really are endless. It’s also kind of fun when you get to tricky letters like X,Y,Z.

I theorise you are building a conditioned response to be happy about review meetings, but this is based purely on my own pseudo science, no actual data to back it up.

Tips

• Pick something that the entire team thinks is nice to eat.
• If you want to vote on what it should be, get a simple system in place. Otherwise you may end up in silly arguments costing more than they are worth.
• After a while it can be hard to get volunteers to make the item, and some people feel they are always volunteering while others do not. I prefer to just buy the things now.

Where Does The Time Go?

Does it feel like you never have any time to focus? Do you feel like time is just disappearing and you don’t know to where? Are you sure there are too many meetings but can’t convince others? Do you spend more time than you feel you should on wasteful activities?

Then you should start figuring out Where Does The Time Go?

It’s very important in creative activities, such as software development, that we get large chunks of uninterrupted time. This enables us to get into a flow and really be productive and innovative. But far too often we find we only get an hour or two here and there.

When trying to motivate why something has to change it’s always good to bring data. This simple tracking system can help you do that.

First, decide on a few different categories for time. Here are some that I like to use, but you should decide on these with your team.

• Planned
  • The work you had planned to accomplish.
• Support
  • Cost of poor quality or usability.
• Critical
  • Unplanned work that was deemed to be critical.
• Meetings
  • Time spent in meetings.
• Administration
  • Things like creating reports, time reporting, etc.

Don’t bother clearly defining exactly what each is used for from the start. You can solve these questions as they come up.

At the daily meeting take a moment for each team member to tick the categories they worked on the previous day. The numbers don’t need to be precise, just close enough.

Compile the numbers every so often and wipe the chart clean.

You will now have data to motivate the things that you feel are wasteful, and you might even discover time is being spent in ways you never even suspected.

Tips

• Take this along to retrospectives to discuss value adding and non value adding activities.
• Make it very clear to the team this is not a time tracking tool.
• Use Post-its for the categories so they can be added or removed.
• If there is something specific you want to remember you can add a Post-it under the category to remind you of it when the retrospective rolls around.
• Track the data over periods of time to see trends.

Event Log

Do you get into your retrospectives and the team finds they only really remember the last few days? Do you find that important events do not always get brought up at the retrospective?

A simple tool I call the Event Log can help with this.

All you need is to mount a large piece of paper (A1) near your Sprint or Kanban board. I personally like these: http://www.magicwhiteboard.co.uk/

Each day at your daily meeting you take a moment to write down things from the previous day that people feel are important to remember.

This can then be brought along to the retrospective either as is, or compiled into a timeline. A quick glance is enough to recall events that would otherwise be forgotten and never discussed.

Also, the act of reflecting every day in and of itself provides benefit because we take time to focus on the previous day before we move onto the next one!

Tips

• Update this as part of a daily ritual. Everytime I tried to use “update it whenever you think of something” it has not been successful.
• You can also use it to quickly gather other data such as:
  • Team happiness
  • Confidence in the plan
  • Amount of quality issues
  • Don’t do too much of this at once, you don’t want it to become a chore.
• Encourage putting successes up there as well. It’s very easy for this to simply be a list of “issues” from the week.
• You can use it to define a focus for the retrospectives as well, by simply dot voting on the events.

Resilience Map

We often talk about working in Cross-functional teams in Agile, and T-Shaped people. There are a lot of benefits with this approach. We are much less likely to become bottlenecked by a particular competence, having teams take things from idea to delivery results in less handover, and we are a lot more resilient to unexpected events. Team members will always come and go, and single ownership of a competence is a huge risk for any team.

But how do we go about reducing this risk?
What do we focus on first?

Do you notice in planning that you need to take something lower priority because there is not enough of one type of competence?
Do you often find yourself saying “That’s a typical Sebastian task”?
Do you worry that if one person leaves you will not be able to manage a specific system?

Maybe you should try out a Resilience Map.

This is one of those cases where a picture says a thousand words:

It’s a fairly simple information radiator created by the team. Along the Y axis we have the technical competences or areas of our product, and along the X axis we have the level of comfort in that area. Then we have avatars representing each team member.

At a glance I can see:

• We have a very serious issue in the payment area of our product, we had better start focusing on doing something about that.
• In the UI and related technologies we have a lot of resilience so, maybe not such a high priority.
• Anders needs support, he doesn’t feel confident in any of these areas.
• Who the best person to speak to is if I don’t feel comfortable in a certain area.

The Resilience Map won’t actually make us more resilient, but it will clearly show us when there is a problem. This is the first step in addressing any problem.

Tips

• Take this along to retrospectives to shine a light on these issues.
• Take this along to planning sessions to make it easer to consider your gaps and their possible effect.
• Use this to motivate to your Product Owner or stakeholders why something is a higher priority than they think.
• Use this daily when pairing up.
• Don’t put everything up there, it will become too much to read and maintain, focus only on the highest priority stuff.
• Choose a regular interval at which to update this, not just the avatars but the focus areas along the Y axis.
• Consider if your organisation is ready for this level of openness, if anyone in the team is nervous about the reaction, keep it as a private tool for the time being.

Recruitment Retrospectives

How we onboard people to our teams is incredibly important, not just because we want to get them up to speed quickly, but because we want them starting off with the right momentum, allowing it to carry on for as long as we work together. We want them to get the feeling “this company has it’s !#!# together, that means I’d better as well”.

I have a friend who has a philosophy he calls “Make the new guy the hero”, which I think is a brilliant concept. But it’s not the bad starts that really gets me, it’s the lost learning opportunity that gets me. Never are people paying as much attention as when they are new, we need to make sure we have a facility for learning from this opportunity.

But before I get into that, a few horror stories to provide context.

This is why we have the Recruitment Retrospective!

So that we don’t miss the chance to learn from these things, so that we can use these mistakes as a learning opportunity and harness them to improve ourselves going forward.

The implementation is very simple. One of the first things we do when a new person starts is to schedule a recurring follow up to capture their feedback on the hiring and onboarding process.

Many companies actually already do this, but the Recruitment Retrospective differs slightly from what most companies do.

Firstly, it is driven by the person who has just been recruited. The rest of the organisation’s job is to support them in this. They invite the people they believe are the most important to the retrospective depending on what they think is most important to improve, and we give them all the support they need. These could be organisational improvements with the onboarding process itself, or more team related things like how we share knowledge for example.

Secondly, experiments are proposed to address these issues next time. We do not simply make statements about “doing it better next time”, but we state specifically what we will do and how. The concerned people agree to make sure these things happen next time and assess if they were successful or not.

You can attempt to improve the onboarding process as a new employee, but the optimal solution is to have learning built into the company culture, and to embrace change.

Thirdly, this process continues for at least the first few months so that they have the ability to continually improve their introduction and constantly keep on the lookout for learning opportunities.

Finally, that person is asked to assist the next new hire with their Recruitment Retrospectives.

Tips

• Provide the person with a contact to turn to when they need help driving a point forward, for example finding the best people to speak with.
• Provide the person a contact who is experienced in retrospectives and improvement initiatives, for example a Scrum Master or Agile Coach.
• Write things down. Since you are trying to improve the process for all future employees as well, it’s good to document and follow up experiments.
• Periodically examine the onboarding process as a whole. With all the changes happening, it’s easy for this onboarding process to grow into a monolith.

Appreciation Flowers

It feels nice to be appreciated.
It feels nice to know that your co-workers notice the little things you do.
It feels nice to get a pat on the back when you have done a particularly good job.

That’s what Appreciation Flowers are all about; making people feel nice!

At your retrospective, have a section on the wall where people can post flowers to one another. A flower can be as simple as a Post-it with a person’s name on it, although I like to make them a nice drawing of a flower as well.

These flowers are used to say a special thank you to someone.

Dedicate a few minutes to take up each note individually and the person who wrote it says a few words about why they wrote it.

The recipient is given the flower to take back to their desk, or wherever they like.

Generally, after a while a bit of an arms race develops around the flowers and people start drawing more and more elaborate things on them in an effort to make their gift extra special.

Tips

• Give flowers to people outside the team as well, they always appreciate receiving them.
• Use the number of flowers given as an indicator of the mood in the team.

Value Poker

This tool assumes you are familiar with the technique of “Planning Poker” if not, take a glance at it first.

We talk a lot about value in Agile teams, delivering it, prioritising by it, measuring it, but value is a very abstract concept. People perceive value differently, they value different things, and have their own ways of reasoning about it. But if we are to prioritise our backlog based on ROI (cost vs value) then we need a common view of the value of items.

This is where Value Poker comes in!

Value Poker is a relative estimation technique, because we don’t actually need to know the exact value of items to prioritise them, just their value relative to the other items in our backlog.

First thing you will need is some baseline items, because to have a relative estimate, it needs to be relative to something. I suggest starting with recently completed backlog items that have already started to deliver some value.

Find the right people

Unlike in Planning Poker where the stakeholders are very clear (the team), this is not the case with Value Poker. Make sure you are involving the right stakeholders. There is no simple answer to who these people are, and it will vary from organisation to organisation, but my simple rule of thumb is find the 6-10 people who will have the most to say about how the backlog is prioritised.

Remember that the team building the product is as important a stakeholder as any other!

Agree on the time scale

Some things only create value over a longer period of time, some things diminish in value as time goes on. We need to agree on what type of time scale we are referring to when we are talking about the value of an item. Is it a week? Is it a year?

This will of course depend on your business context.

Find some 2’s

• Find an item that is close to the smallest value item in your backlog, not the smallest, but maybe second smallest.
• Everyone must agree that have a very good idea of the value of this item.
• Try to find something with very solid value motivation.
  • This saves us X hours per week.
  • This pays us X amount of money a week.
• Arbitrarily assign this it item a value of 2.

In Planning Poker we only have the development team, here we will be representing a lot of different facets of our organisation. Take the time to find several 2’s that represent these various standpoints and perspectives in your organisation.

You now have a baseline!

Find some 5’s

In order to confirm we have reached a baseline everyone agrees on, we want to find some more items we all agree of about double the value as the ones we just picked. The same rules as before apply:

• Everyone must agree that have a very good idea of the value of this item.
• Try to find something with very solid value motivation.
  • This saves us X hours per week.
  • This pays us X amount of money a week.

We have now confirmed our baseline!

Start Estimating

From this point on, it works just like Planning Poker.

• People each decide privately what they think the value of an item is.
• Everyone reveals their estimate at once.
  • If everyone agree we have the estimate.
  • If there is disagreement, we must motivate to each other the reasoning behind our estimates, and listen to others do the same.
• We repeat this process until the estimates converge or we decide to table the discussion.

We now have a common unit with which we can prioritise, ordering the backlog should now be trivial, right? Of course not, but it sure helps a lot now that we are all speaking about the same thing. Estimating value in this way of course lacks precision, but let’s be honest, was having no estimates very precise?

The true value in this activity is around the discussions that spawn as a result of it.

Value Poker helps to build consensus among those involved in the discussion, it helps us reveal our assumptions, opens the floor to discussions about the value of things, and provides us a metric to follow up. Just like Planning Poker!

Tips

• Take some time to discuss the different ways in which we perceive value; time saved, money in, quality, customer loyalty, etc.
• Do a quick “bubble sort” in the beginning of the discussion to make finding those 2’s and 5’s easier.
• Tell everyone the infinity card is only to be used in cases of “paradigm shifting” levels of value.
• Empower your Product Owner to make a decisions in cases where the people involved agree that they will never be able to reach a consensus.
  • Have everyone agree up front to abide by the Product Owners decision in these cases.
• Periodically re-establish your baselines as your knowledge of value in your organisation evolves.

In-Line Definition of Done

This tool assumes you are familiar with the Scrum tool “Definition of Done”, if not, take a glance at it first.

Are you following your Definition of Done? Do you know what it contains? Are you often forgetting the small things you need to do when building your product? Is your current process prone to human error?

If so, you might consider using an In-Line Definition of Done to make it more prominent in your mind.

Definition of Done not only keeps us honest in our teams, prevents us from cutting corners whenever we like, but it also serves as a reminder of how our process works so that the small stuff is not forgotten.

Most teams have this posted prominently over the “Done” column of their board, but you would be surprised how this is easily ignored, especially in crunch time. If this is what is happening to you, try this:

• Break your Definition of Done into a short checklist.
• Make a template for the tasks and stories that you use of your board.
• Make a ceremony out of checking off every item before tasks and stories move to done of the board.

Simple as that!
Your Definition of Done is now harder to ignore.

Tips

• Sometimes the checklist won’t make sense for every single item, get in the habit of crossing out the ones that don’t fit. This will make sure it’s an active decision to ignore them.
• If this happens too often with an item, consider removing it.
• Take these items to your Retrospective and ask the question “What can we automate from this list?”.

Not Now Backlog

Maintaining a Product Backlog can be a costly activity, and it gets more and more costly the larger the backlog becomes. Actually, the cost is not the worst part of having a large backlog, the real risk is that it will become so unruly that it won’t be used to its potential.

A useful backlog looks a bit like this:

At each “level” of the backlog we have just enough information to enable us to do what we need to do next, and do it well. A useful backlog provides transparency to our entire organisation about what we are working on now, what is coming next, what will happen in the future. It also provides the information on what is ready to be actioned immediately, and what requires more investigation or elaboration before it can be actioned.

A useful backlog is an immensely valuable tool, which enables us to make the best decisions possible, and take the right actions at the right time.

Keeping a backlog in a useful state is a very hard job. In Scrum for instance, we have a role whose primary responsibility is working on the state of the backlog, and even in Scrum this is often not enough. That’s because maintaining, understanding, and harnessing the backlog requires a contribution from all the stakeholders involved.

An unruly backlog is expensive in a lot of ways.

So, the solution is simple right? Throw stuff away that you don’t need!
If you are doing this, great for you, stop reading now.

But if you find your backlog is hard to maintain, it is a place where requests go to die, and people are always resistant to throwing things away, the Not Now Backlog might just be the tool for you.

I will never quite understand peoples resistance to throwing items away. I am of the opinion that if something is important it will come back, and that if we haven’t used something in the last two years it’s highly unlikely we will be using it ever. But I get surprisingly little support for this way of thinking - people worry about traceability, and that some piece of vital information may be lost. So, to soothe those fears we have the Not Now Backlog.

First, you need to decide what now means to your organisation. This can be a tricky question to answer, but I generally ask myself and my stakeholders a few questions:

• How far into the future can we reliably predict our priorities?
• How far into the future do we need to predict our priorities?
• How often do our priorities change drastically?
• How many items can we commit to maintaining?
• How much are we willing to spend on backlog maintenance?

This results in a lot of discussion, but in the end what we need to arrive at is something like “we want to be able to see as far as X months/weeks/days into the future”.

After that it’s very simple, we go through our huge unruly backlog and ask ourselves “Do we realistically think this will be a priority within the next X months/weeks/days?”.

Everything that is a “No” goes into the Not Now Backlog.

Congratulations, you can now start focusing on bringing value to the backlog you have.

“But now we need to maintain that backlog too!” I hear you cry. The only thing I can say about that is, I never have. In all the times I have used this tool, I have never again needed the items that were put in there, they simply went there to die. But luckily we saved them just in case ;-).

In case I have not made it clear, this is a tool I think we should be able to do without, it is a suboptimal solution to what I consider a larger problem. But, maybe it’s a necessary first step.

Tips

• If you are having trouble finding the now interval, just start with 6 months.
• Do not put things here that you know you’re never going to do, if you can get everyone to agree it will never be done, throw it away.
• Try setting a work in progress limit instead of a time interval and simply say, the backlog never contains more than X items.
• Use this in environments where traceability is mandated by law or regulation.

Visualised Flow

There is nothing more crucial to the success of a product than successful collaboration, at least thats what we believe in the Agile world. Collaboration is hard in any context, but it’s basically impossible when people are talking about different things.

Are you having Sprint Planning meetings that are long, hot, boring, it smells bad in the room, and in the end everyone agrees to a Sprint just to get out of there?

If the answer is yes, then Visualised Flow will likely help you a lot.

Do your stakeholders know what you’re working on at this moment?
Do they know what you are going to work on next?
Do they know if the things you have just finished are actually in production or not?
Do they know what actions they need to take to get their items to the front of the queue?

If the answer is no, then Visualised Flow will likely help you a lot.

This is one of the most steadfast and valuable tools in my toolkit. It is usually one of the first things I look for when I enter an organisation and one of my first objectives if it doesn’t exist.

Not only can visualising this process increase transparency throughout your organisation, but it is built to facilitate and support collaboration across your organisations.

The goal is to visualise how value flows through your organisation, from the moment something is requested to the moment it arrives to the intended recipient. Anyone in your organisation should be able to glance at this tool and know what the status of an item is.

Find the In-Flows

First I start out by trying to figure out where requests for work come from. Items don’t just magically appear in the backlog, they originate from somewhere, whether this is particular stakeholders, or different products will depend on your context. Some common examples shown below.

This allows our stakeholders to prioritise as individuals, to consider what is most important to them, but eventually everything gets moved into the backlog area where we need to make decisions about how we will balance the conflicting priorities. This helps to facilitate those discussions, because it is impossible to ignore the priorities of other, they are right there in your face.

So we end up with a list of items that has been prioritised against one another, but these items are very rarely in a state where we can simply pull them and start working.

Refinement

Usually some form of elaboration is required before items are actually ready to be worked on. Most people refer to this as refinement or grooming of the backlog. If you have a specific process in place for this you can visualise it, if not here is a very simple starting point.

In this example we have items under investigation from the Product Owner and items that need investigation from the team, both can easily see things that are awaiting action from them. Your process may be much more elaborate than this, maybe you require a customer sign off, or UI mockups, or you have a prototyping phase. Regardless of what your process looks like, the objective here is to reach a state of “Ready” where items can simply be pulled from there into implementation.

How “Ready” is defined will vary from organisation to organisation, I highly recommend you consider a formal “Definition of Ready” for this stage, but if you don’t have that yet a simple starting point is “all the team members agree we could work on this tomorrow”.

This is the state most people think of when they think of a backlog “Ready”. The backlog “Ready” is simply the top of the backlog from where items can be pulled.

Implementation

From the team’s perspective things are now much easier, we have a prioritised list that is defined to the level of detail that we require to actually work on it. We simply start pulling things into the implementation stage, maybe this is a Sprint if we are using Scrum, or simply In Process if we are using Kanban.

The Outflow

If you are practising continuous deployment or releasing to production at the end of each Sprint, then you can likely skip this step. Ideally we all want to be in the situation that “Done” on the teams board means completely done, as in delivered to a customer who is happy with it, but not all teams are in that state yet.

If you are not yet at this stage, you need to also visualise what happens after items are done by the teams, and before they are actually delivered.

In this example we have a “Deployment Test” phase, and then we hand over to the deployment team so we have a waiting area for that. This helps a lot in this example because people start to ask questions like:

Regardless of what it looks like for you, you need to make each stage clear so that if items are not actually in production, everyone in your organisation can see that.

Seeing The Whole

Put it all together and what do you get? You get a overview of your organisation’s entire process flow, the ability to make more informed decisions and have collaborations where everyone is talking about the same thing.

Abstraction

A side benefit of this system is it allows abstraction where needed. Probably the development team has a team board that carries more specifics about each items breakdown and progress, but our entire organisation doesn’t need this information. It would merely confuse them to have that level of detail, thereby reducing our transparency.

Never confuse visibility with transparency, information can be highly visible but if the person seeing it can’t interpret it, it’s not transparent.

The same of course goes for all stages here, maybe the Product Owner has a defined refinement process, maybe the deployment team does, all of that is visualised to appropriate detail here.

People and Interactions over Processes and Tools

It is very possible to setup this entire system and have no positive effect at all from it, because this is a tool to facilitate conversations - not replace it. People understand how this works because they are involved in how it’s created and used, they are present when their items are moved and elaborated. If you are using this as a way to not speak to each other then it won’t work.

Tips

• Use different colours to illustrate different inflows so they can easily be tracked throughout the process.
• If more detail is available for a specific stage, for example a teams Scrum board, include where that information can be found in this flow.
• Value ease of use over functionality when choosing a tool to do this, I use http://www.kanbanflow.com
• If you don’t know your process today, start simple and add the missing steps as you discover them.