Creating the Sprint Backlog in New Scrum Teams

If you’re new to Scrum, here is something you need to know about teams first trying it out…ready??

…drumroll…

The team doesn’t know what they need to do

There, I said it. Whew, glad I got that off my chest.

In Scrum, we ask team members to break product backlog items (typically stories), into tasks that take 16 hours or less to complete. You will find that, most of the time, the team will have incredible difficulty in doing this, and they will likely come up with tasks such as “analyze, code, test”. Bleh. Those are B.S. tasks that really don’t mean anything. It’s hard to define “DONE” for those types of tasks. You may have to accept those tasks in the beginning, but it is your responsibility as a Scrum Master to coach the team into creatively thinking through task definition.

Here are some reasons I think teams may have a hard time defining tasks.  It is best to look at all of these as impediments, and your job as a Scrum Master is to remove them.

• Lack of Empowerment
  Teams under the tyranny of “traditional” development are rarely empowered. They are used to being told what to do. While creating solutions, team members will actually do what needs to be done and then move on to the next thing. The problem is that they’ve never had to articulate the steps they take to complete what they need to complete.  And, to top it off, managers rarely understand what it “really” takes to deliver a solution. 

  This will not be a quick fix.  You will have to work with leadership and come up with a strategic plan on how to empower people.  In the meantime, even though you tell the team “your empowered’, if the rest of the organization does not support it, there will be constant struggle.  However, as a leader, it is your job to work both sides of the fence, i.e the team and the organization.

• Fear
  In an extreme command-and-control environment, people lose all common sense. They are not confident making any decisions, let alone actually thinking for themselves. 

  Here, the team will need lots of praise and protection.  If they know that you have their back, they will, over time, come out of their shells.

• Lack of Knowledge or Skills 

  If the team is new to that domain, or the team just does not have the skills, i.e. a Cobol programmer “trying out” Java development, there is no way they can effectively decompose stories into tasks.

  This is one of the toughest situations to deal with.  If the team is just the wrong team, the only thing that can be done is to escalate this impediment to leadership.  This one is particularly hard because I guarantee that there will be others who think some of those on the team DO have the knowledge and skills, likely because those folks are “well liked” or popular.  Just remember to be honest always, and over time, change will happen.

• “The Dominator” 

  Sometimes there is one person on the team who holds the key. They know the domain, they know the technology. No one else does. THEY are the ones who define the tasks. If the tasks aren’t good enough, who cares, as long as “The Dominator” is okay with them. This is a tricky one. It is your responsibility to either a) get them off the team or b) clearly set the expectations and time-box the needed change in behavior.

If you are a Scrum Master or coach on this team and you don’t have “tribal” knowledge, it will be a true test of your patience.

But, hope is not lost! A while ago, I was in this situation. I was in a sprint planning session, and I saw the familiar signs emerging…”Ummm…yeah…we need to analyze”. “Oh, I suppose we need to code too”. UGH. I was helpless. Luckily, there was a strong technical lead attending that understood the domain and technology. He patiently walked the team through the decomposition of the stories into “real” tasks. It was a real humbling experience for me. I thought I could get ANY team to decompose stories into meaningful tasks. Boy, was I wrong.

So, if you’re in this situation, determine the “root cause” of why the team can’t decompose stories into meaningful tasks. If it’s an impediment, handle the impediment. If it’s because you are lacking the knowledge necessary to coach the team, find someone there who can.