How Kanban Software Makes Backlog Grooming Simple

By: Steve Stedman

CEO at Uzility Software

Some of the first backlog grooming meetings that I participated in as a scrum master were extremely painful. I would be working with multiple product owners and many of them weren’t using the same system to manage their backlogs. Some were using Excel to manage their back log, others using a text file, or a Word document. With any of the typical office tools, it was challenging to organize the backlog into a way that workflow could be updated, allowing the product owners to get their backlog items to the state defined in our definition of ready. Then, once the backlog items were ready, someone would have to transfer the items from Excel or Word into some other system, or to eventually print cards. I had a hard time understanding the value of agile when so much time was being spent just copying and pasting in Excel.

I began to realize quickly that creating a uniform location and structure to building a backlog was an important part of the agile process. There was a need that was not being met within my project teams and I decided to fix it. Part of the reason that I started down the road to the creation of Uzility was to eliminate the need for the painful copy and pasting from excel to other systems, and instead have an easy drag and drop process that integrates card creation and backlog management into the Kanban board.

The way the backlog grooming system is structured means that the product owner can put as many cards into their backlog as they want. The most important cards get dragged to the top of the column, indicating their priority.  The backlog items with the highest priority are given a final edit, and dragged into another column where developers can then take the prioritized backlog and use it in sprint planning.

Your backlog may look something like this.

BacklogGroomingBlogPost1

 

If you want to prioritize card #20 “Add a support page” as the highest priority, simply drag it to the top of your backlog. The prioritized list would look something like the following:

BacklogGroomingBlogPost2

Now that “Add a support page” is the top user story, you can click the edit button, or double click the card to get more details. Keep in mind that the numbers shown on the cards are the card number, not the sort order. In this case as shown below, there are no more details, the user story has not been completed yet.

BacklogGroomingBlogPost3

To complete the card, fill in the details section. It might look something like this:

BacklogGroomingBlogPost4

Next click the “Acceptance” tab and hit the “Add Acceptance Criteria” button to start adding your acceptance details.

BacklogGroomingBlogPost5

Notice the “Save and Add Another” button. This allows you to quickly add several acceptance criteria without having to leave the form and come back in.  After adding a few acceptance criteria your acceptance page may look something like this.

BacklogGroomingBlogPost6

If you have files to attach, you can use the “Files” tab.

At this point your new card should be finished and ready to go to the Sprint Planning Stage.  Repeat this process for the rest of the User Stories in your backlog an you will be ready for that next sprint planning meeting.

Related topics:

  • Uzility
  • Planning Poker
  • Backlog Grooming
  • Acceptance Criteria

Sprint Planning

Agile Word Scramble – Sunday Fun

AgileTermsWordScramble

Unscramble each of the clue words.
Copy the letters in the numbered cells to other cells with the same number.

Sunday Fun – Agile Word Search

AgileWordSearch

 

The following words are all placed in the grid above.  Find as many as you can.

ACCEPTANCE AGILE BACKLOG
BURNDOWN BURNUP CHICKEN
CUSTOMER EFFORT EPIC
ESTIMATION FIBONACCI GROOMING
ITERATION KANBAN MANIFESTO
PIG POKER REFACTORING
RELEASE SCRUM SCRUMMASTER
SPRINT STAKEHOLDER STANDUP
STORY TASK TIMEBOX
VELOCITY WATERFALL WIP

Uzility Training Friday at 2:00pm Pacific time.

Friday at 2:00pm pacific time (US), I will be doing an hour long demo of the Uzility kanban board system.  This will be about a 40 minute long free broadcast showing how to use the Uzilty system.

Here is a link to the event on Google plus.

https://plus.google.com/events/curc1k7uv588n1ks53q9mm39ebo

You can RSVP or just show up to watch on Friday at 2:00pm.

Here is a list of all the Uzility topics I will be training on.

TrainingList

 

See you there.

See Also:

Kanban Boards for Non-Software Projects

I get asked all the time, can Uzility be used for non-software projects? The follow-up question is usually:  Can you change the column headings, add new columns?

 

The concept of Kanban boards works great in many situations, you don’t need to be building software to use a kanban board to track your progress.

Kanban Boards for Family Activities

My wife and I use a Uzility kanban board to track projects around the house. She has an idea that we need to remodel the kitchen, and I think we need to paint the family room. Over time we just establish a list of ideas that go into a column called Backlog. We then sort the backlog based on budget, available time, and time of the year. We have some pretty epic stories in the back log, like remodeling the kitchen, and some quick and easy items like Wash Windows, or rearrange the furniture in the family room.

We event have a second kanban board for family trips or activities. If my wife has an idea take the family on a ski trip to Canada, she just throws it in the list, and if I want to go fishing in August, I throw it in the list too. We sort the list, determine what we have time for, and what we can afford. If we don’t have time, or budget for a bigger trip, we just move a more affordable or shorter trip up the list to take the place of the one that is blocked.  This has worked great, and has certainly improved the overall communication around trip planning.

With uzility we can change the columns to represent different workflows, for instance on the trip planning board we have the following columns Dreamboard, Planning, Booked, and Done. It is surprising how many trips or activities we have been able to move into the done column since we started using the system.

FamilyBoard

With either of these family boards we don’t have daily stand-up meetings, but we do have occasional backlog grooming and planning were we discuss and decide on what is next and how we are going to get it done.

 

See Also:

Agile T-Shirt Sizing

T-shirt sizing is generally used to give more of a rough estimate in sizing, and are usually used before all the acceptance criteria are worked out on the story. The t-shirt sizing method allows the team who will be doing the work to give the product owner a wild guess of how large a task may be.

cloth_t-shirt
This can be useful in backlog grooming. Let’s say a product owner has 5 stories in their backlog, and that product owner doesn’t have any way to gauge the relative size between them. Additionally let’s assume that all the acceptance criteria haven’t been worked out yet either. The product owner is just looking for an idea of relatively how big tasks are.
When you are t-shirt sizing, it’s a good idea to keep it simple with only 4 sizes, Small, Medium, Large and Extra-large. Sometimes I hear comments like that’s an extra-small size, or I have even found myself saying that that user story will be at least 4 extra-larges, which isn’t the best practice. Anything that is larger than an Extra-large is simply too large to estimate, or is too epic.
You might have two very small tasks, one is to change a single misspelling in a word and you know exactly where the change is, one of those tasks that might take you 15 seconds to find and to fix. Then you may have another task that requires changing several files, and some more testing. Both of these tasks however compared to the others that you are estimating are small, and therefor are given the t-shirt size of small.

Who can t-shirt size?

Only the people who could be doing the work should be allowed to provide t-shirt size estimates. The product owners and the scrum master should not be giving t-shirt sizes. I heard a funny comment from a product owner who stated that the team estimated it as a medium, but I rewrote the story as a small. I later learned that the PO did not talk to the team to get that small estimate, he just assumed that based on his changes it would be a small. This is very dangerous, PO’s should not be allowed to estimate t-shirt sizes or points.

 

While you are here, don’t forget to take a look at Uzility.com for Agile Kanban Boards.