Are you frustrated with your board? Maybe three columns don’t offer you enough information. Or maybe you agree with me that teams need to create their own boards. (See the Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics series.) While you’re intrigued by how to create your own board, you have zero money to spend. Not to mention your team is frantically trying to progress through all the “tickets” or “PBIs” (Product Backlog Items).
You can create your board even in the midst of tons of work. Here’s how I work with teams (management or product teams) to create their own boards.
I start with paper.
Start With a Paper Board
Yes, paper. Here’s why I use paper:
- The wall or bulletin board limits the number of cards you can post. That limits the cognitive load and possibly the WIP for the team.
- The size of the stickies/cards limits the size of the work.
- You can move columns around any time you realize you don’t have the “right” flow. (The right flow reflects your work.) You can customize and experiment as you work.
I’ll ask you later to set up a camera to look at the board when you’re not all in one place. If you don’t like a camera pointed at a wall, consider a shared spreadsheet.
Whatever you do, consider how you can make the board flexible enough so you can evolve the board as you work.
1. Prepare Your Board
Decide where you will set up the board. You might use a wall. I prefer a whiteboard or bulletin board.
Now, make dividers using blue tape. If you already know how the work flows through your team, make a column for each state. If you don’t know, consider these columns:
- Prepare the work for or with the team.
- Ready to Start
- In Development (I include TDD other development thinking here. If you include the testers as you think, you’ll make a much more robust product.)
- A possible “Dev-Done” column so you understand when system test can start for a given item.
- In System Test
Management teams require different columns. I often have these columns for management teams:
- Ranked backlog (mostly for decisions)
- Analyze issue.
- Wait for decision from others.
- Risk management
- Decision needed post-action
- Stuck items
I’m sure you will need different columns.
Don’t worry about limiting WIP (Work in Progress) yet. Instead, make sure your board reflects the flow of your work.
2. Prepare Person Identification for the Items on the Board
If you have a whiteboard, buy magnets that are large enough so you can print a picture of the person’s face. Same idea with bulletin boards, except use large pushpins.
Now, print a picture of each person’s face on your team. Glue each person’s picture to one magnet or pushpin.
Why just one person to one magnet/pin? So you don’t have people working on two or more things at once.
If everyone on your team is supposed to work on more than one item at one time, measure your cycle time. I guarantee everyone is wasting time with multitasking. (Even managers. See the Managers: See Your Cycle Time post.)
3. Prepare Stickies or Cards for Your Board
If you’re not in person, the person who has the camera will need to write down the items on the cards or stickies. (This is an excellent reason to keep the card contents short.)
Cards or stickies need to be large enough so people can read them by camera even if you’re all dispersed.
I recommend the equivalent of 3×5 inch cards. Why? Because if everyone needs to see the cards, that’s large enough to write a few words to a sentence on the cards and not so large that the camera can’t zoom in on the cards.
Then they can see who’s working on what. Want to measure cycle time? Make a note on each card for the day and time someone moves the card.
Now, you’ve got a board where your team can experiment. What if I haven’t convinced you to start with paper? Use a shared spreadsheet.
Create a Shared Spreadsheet
I prefer paper because it limits the incoming information. However, if you want to use a shared spreadsheet, consider these ideas:
- Set the print area to 10 columns and 10 rows. Why? Because that mimics paper. (Does your team deliver more than 10 items in a given time period? If so, increase the number of rows. Your team might have more than 10 states, especially if you’re already using kanban and pull from the right. In that case, increase the number of columns.)
- Expand each cell so you can easily read the contents of each cell without having to use a magnifying glass. Make that print area so it takes up the entire screen on a larger monitor.
- Use a macro to see how many items a single person is supposed to work on. Create a warning so your team can decide what to do.
Spreadsheets can work, as long as you think of them as paper. It’s all about seeing the work.
How to See Your Board When You’re Distributed.
“But we’re distributed.” That’s okay. Get an extra camera, possibly mounted on a tripod. Ask someone with wall space to mount the whiteboard or bulletin board on their wall. That person will have to move cards or stickies as the team progresses.
What if you don’t want to be bound to one person? Ask everyone to keep a copy of the board on their walls. Maybe rotate the job of taking a picture of the board through the team.
Boards with paper are easy to update. You can’t write a gazillion words for a story—you have to have a conversation. The physical wall prevents a team from taking in too much work. And if you put pictures of the team members on the magnets or pins? You won’t overload people.
The best part? You can change the columns whenever you need to. You don’t have to ask anyone’s permission to change your team’s flow of work.
What’s Missing From This Board
Here’s what I did not yet include in this board:
- How an item moves from column to column. How do you know an item is ready to move from one column to another? (In a real sense, you distribute the “done” criteria across the board, in each column.) I did suggest a Dev-Done column, but maybe your team works differently.
- WIP limits. I didn’t suggest you add WIP limits either in a given column or for the entire board.
- Anything else that kanban recommends. (I happen to love a kanban approach, but this post is about helping your team experiment their way to their success. Not what I think they should do. Hehe. Consider reading the Kanban Guide for everything I left out.)
In addition, I am sure the columns I suggested are not correct for your team. Your team works differently. That’s why I recommend you experiment.
Experiment With the Board
I keep saying, “experiment.” Here’s what I mean.
Let’s imagine you think you might need an “Analysis” column after “Ready to Start.” That’s because, in this product, you’re assessing various architectural or design approaches. So, while the team works on this product, you add that column.
Then, in a few months, or when the team works on a different product, you remove that column.
Or maybe you integrate testers with your developers and you almost always mob or swarm the stories. Do you need to differentiate “In Development” from “In System Test”?? Your team decides.
Guesstimate for This Board’s Costs and Value
I figure a paper board like this might cost $50-$100 total. You might have recurring expenses for stickies, cards, and markers. A shared spreadsheet has zero cost, although you will have to work a little to emulate paper.
However, the value is enormous.
When teams create tactile boards, they often realize they can see more data. They might want to:
- Capture cycle time.
- Add more columns to understand and see the various bottlenecks.
- Subtract columns because the team changes how it works.
I strongly recommend every team review how well the board works for them each retrospective. Mark Kilby and I recommended paper boards in From Chaos to Successful Distributed Agile Teams. I recommended paper boards in Create Your Successful Agile Project.
You don’t have to be frustrated with your board. Build your own on paper and then use a tool. The tool isn’t strategic—the customer outcomes are.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: How to Create Your Own Team Board Without Spending a Ton of Time or Money
Opinions expressed by Java Code Geeks contributors are their own.