Increasing Transparency with Index Cards - The Product Backlog

Photo by Chris Campbell

Photo by Chris Campbell

Years ago when I was a relatively new Scrum Master, I found myself struggling to help my team and Product Owner with the product backlog. It was stored in an electronic tool and contained just over 300 items. We could only review a few items in our backlog refinement sessions. When the Product Owner said an item could move down in the product backlog order, I wasn’t sure if she meant I should move it just below what was visible on the projector screen or to the bottom of the backlog. Transparency of the product backlog was a challenge.

Just before that time, a mutual friend introduced me to Gary McCants when we ran into him at a restaurant during lunch. He had a stack of index cards and a Sharpie marker with him as he was working with a Product Owner to write user stories. Gary is a local agile coach/mentor and co-founder of the DFW Scrum user group. I became a member of the group and learned a lot from the meetups. Since I was struggling with a big product backlog, I decided to ask Gary for advice one evening.

Index cards.

That was my takeaway from our conversation: make the backlog visible by putting it on index cards. And so I wrote each backlog item on a card—all 300+ of them. Multiple Sharpies were sacrificed in the process. I taped each card on the wall of the conference room where we held our backlog refinement and sprint planning sessions. And so the next meeting….

“Whoa, what is all this?”

The group finally saw the product backlog in all its glory. Right away, duplicates were discovered and grouped together. Outdated/no longer needed items were tossed. It was incredible. Our Product Owner ordered the top 25 items and moved them to a different wall. The level of engagement and communication was incredibly high—index cards are magical! From that point forward, we used the index cards to have conversations around, and the electronic tool became secondary.

How do you create transparency for your teams?

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Managing Risk in the Product Backlog

Photo by symphony of love

Photo by symphony of love

I recently attended the Agile Coach Camp in Atlanta, and one of the discussions there was about how to manage risks and dependencies in large agile projects.  I shared some of my ah-ha's with my peers, and we've been talking more about how risks are managed and made visible in the product backlog; we're exploring the idea because in the past we've been training teams to keep a separate risk log, and we've seen mixed success with that approach.  

In addition to possibly adding risk mitigation actions to the product backlog, there's been talk of "rating" the relative risk of stories; Rally's Portfolio Manager includes a "risk score" field for stories.  This sparked the conversation of what types of risk should be considered in that risk score: is it just delivery/technical risk, or does it also include the business risk?  And is the score determined by the development team or stakeholders?

What are your thoughts on defining a risk score and using it to help prioritize stories?  Is this something that could help drive the right conversations and decisions, or is it adding too much complexity to the backlog?

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Conflict in Virtual and Distributed Teams

Photo by Azri

Photo by Azri

My coworker Jane shared an interesting article on how to manage conflict in virtual teams that got me thinking about some of the challenges I've seen with virtual and distributed teams.  The article points out that successful virtual teams tend to have online discussion boards in an shared virtual workspace, which is probably quite true, but it implies that such tools are the key to avoid or manage conflict. 

Communication is the answer to avoiding or managing conflict, and an online discussion board is just one way for team members to communicate.  It's been said that software development is a cooperative game, so when team members are not collocated, cooperation is more difficult.  I encourage teams to use the richest synchronous communication tools possible because it helps to ensure shared understanding. It's quite easy to tell Team Member A to pick up the phone and call Team Member B who is hundreds of miles away instead of sending an email, but it won't work if Team Member A cannot make long distance calls from his desk and he does not have cell phone reception because he sits in the basement of the building.  

If you have a virtual or distributed team, make sure its setup for success by having the right communication tools available.  Conflict will happen in any team, and the ability to communicate openly person to person is the only way to resolve it.  Effective communication requires relationships, and relationships are built on regular communication.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

The Trouble with Tools

Photo by Anthony Beal

Photo by Anthony Beal

Inspired by Ty's "My Fear of Robots, er... Tools" posts (parts 1, 2, and 3):

The Agile Manifesto tells us that we value individuals and interactions over process and tools, but it is quite common for organizations to adopt an agile tool that all of their teams must use.  These tools are intended to enable managers to see at a glance what work is in progress and what work is coming.  To show how productive teams are and where they are blocked.  To roll up reports across multiple teams to show project/program progress.  But I've observed that the realities of using a tool are quite different.

1. Teams don't understand how to use the tool effectively.  Regardless of the tool, odds are it is more complicated than using index cards on a wall.  Teams that do not understand scrum thoroughly and have not used index cards in the past struggle the most--which features in the tool need to be used?  Which can be ignored?  What should team members be looking at and when?  Teams are less likely to be looking at a task board during their daily scrum, so the feeling of committing in front of your peers is lessened.  It is harder to see the big picture view of the sprint, so the team might not recognize when it needs to swarm. 

2. Managers don't understand how to use the tool effectively.  They look at reports from their offices and don't discuss them with teams.  Teams and projects are not setup properly for roll-up reporting to be useful.  Reports are looked at more often than backlogs, so the focus is on where the team is and where it has been rather than where it is headed.  They aren't having meaningful conversations or making decisions based on the information available.

3. It's an information refridgerator rather than information radiator.  Burndown charts are not reviewed as a team, and conversations about whether or not the sprint will be completed successfully are not occurring as often.  The data in the tool might not be updated as often as it should--backlogs are stale and tasks are outdated.  There's no way of knowing who is looking at the tool, when they're looking at it, and what they're thinking based on it.  Tools also allow users to add more information to backlog items, so historical notes and attachments are added that also get outdated.

I wish more teams and organizations knew their processes before moving to tools.  Focus on behaviors that are effective and translate them to a tool instead of picking a tool that seems like the right thing to use because it's popular.  Stay low-fidelity for as long as possible and consider alternative ways of sharing information before moving to a tool; if working within a distributed team, it's acceptable--perhaps even preferable--for each location to have physical scrum boards setup.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.