To Backlog or Not to Backlog

My Experience on How to Build a Backlog

27 August 2013


 
Nowadays lots of people wonder why they should build a backlog and why it should be on a real board rather than an electronic one. Here are some thoughts I would like to share with you, and I would like to have your opinions on this matter.
 

Why should we have a board?  

The board's main function is to allow the team to visualize the remaining work (tracking) and facilitate daily synchronization (re-planning).

Every day the team gets together, looks at the board (which contains the committed work), and the team replans the day: What should we do today in order to accomplish our goal?

Because of this, Scrum boards should be:
  • Simple. Don't add too many columns and unneeded items.
  • Big. Everyone sees it, knows where it is, and -- just by looking -- knows where the team is regarding the goal.
  • Accessible. Everyone on the team can see it and update it; it's their plan, they own it.
  • Flexible. It should be easily improvable and adaptable to team needs.
  • Interactive. It should be appealing -- people should touch it and play with it, for example by moving cards from one column to another. If you touch it and name it, you own it (yes, tasks are like puppies).
  • Visible. The board should be the kind that you can't avoid when entering the room; that makes it a good way of keeping questions answered without pressuring or interrupting the team.

Paper or electronic?

I say it should be something "real" you make with markers -- paper or whiteboards. I can give you at least 3 reasons to stick with a physical board rather than using an electronic version:
 
1. Electronic boards are accessible, but they are not visible (unless you can afford a big touch-screen and display it in the middle of the room). It's true that everyone can access a drive or tool, but it's not something you see just by entering the room. You have to log in or search inside a folder, so it's "hidden."
 
2. Electronics appeal to individuality. Paper leads to collaboration.
If you have a tool:
  • You'll update your tasks before the stand-up for the sake of speed, and this way you lose interaction.
  • Alternatively, you'll update during the stand-up, and this way you'll increase the time of the daily stand-up (and waste time).
If you use paper, you can speak while you move post-its or make edits. Everyone around you, listening, will also see the task you are talking about.
 
Additionally, science -- that lovely lady -- says there are three types of learners:
  1. Visual learners (about 60 percent of people)
  2. Auditory learners (about 30 percent of people)
  3. Kinesthetic (tactile) learners (about 10 percent of people)
(For more details, check Neil Fleming's VAK/VARK model and here.)
 
This means that if you use a real board on the wall, people will not only listen but also see what you are talking about; and as you move your tasks through the board, you'll also touch them, perceive the tasks as something material, something that exists. So with a simple board on the wall, you can reach everyone's attention.
 
3. There is nothing easier and simpler than paper/ boards to work with. You can update, improve, erase, add. . . .
 
By using a tool, you are bound to what it offers. If it's an electronic tool, chances are you'll need to implement extra functionalities (and test them, and train people, and so on). While you're getting the budget or permission for this, I've meanwhile created zillions of boards with my team.
 
So my advice is: Stick with paper or whiteboards. Use this method, improve it, reach the best possible solution. Then, if still you want an electronic gadget, go for it, and good luck.
 

My board as an example

I made a draft of the board we use. If you like it and find it useful, you can just reproduce it in a large size. (Extra tip: Don't make it too big, or else it will look empty and everyone will feel tempted to add more tasks than those that can be handled.)

backlog draft short

If you get back to the basics, Scrum boards have only four columns:
  1. User stories
  2. Not started (tasks)
  3. Ongoing (tasks)
  4. Done (done-done, no buts -- done as in ready to go live)
Although I love simplicity, I've faced teams for which testing (QA, or quality assurance) was a bit forgotten. So we had to make this visible in order to deal with it. These teams had no QA experts, and developers would run away from testing as fast as possible. When they had just an "Ongoing" column, tasks stayed there in a kind of limbo, or they would go to "Done" without being really done.

So we split "Ongoing" into DEV and QA. Having these columns was the way we found to show exactly what was under testing. When this column grows too big, everyone knows it's time to jump in and do some testing.
 
You can use this idea or not; it's up to you and your team. Some teams just create testing tasks and take them through the flow: Not started -> Ongoing -> Done. That works perfectly, but only if you have someone who cares about QA inside the team. Otherwise, again, everyone will delay those tasks as much as possible.
 
My advice is: Don't get influenced by anyone except by your team. Do what your team needs, and then keep improving it. Target simplicity and transparency, and everything will certainly go OK.
 
Share your own board with me -- I appreciate new ideas!
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (2 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.