Skip to content

Scrum Puzzle #5

iStock_000012609528XSmall

Forgive me Scrum Puzzlers for taking so long to post a new puzzle. I’ve been busy with a side project which will very soon become a lot more than a side project. In exactly 2 weeks I will be self employed! I have started Growing Agile with my good friend and fellow agile enthusiast Sam Laing. We are looking forward to a whole new adventure next year, which I imagine will inspire quite a few Scrum puzzles. Anyway onto my solution to puzzle #4:

My first instinct is to ask what problem you are trying to solve. I personally don’t like estimating tasks at all, but that stems mostly from having seen those estimates abused. Usually I let the team decide what they want to do. I even had a team once that drew a gantt chart on the white board before they would commit. In the example, it seems that the issue is more about developers not being able to collaborate on tasks because they can’t communicate their progress effectively and about not being sure if they will meet the sprint goal or not. Given the resistance from the team towards estimating in hours, I would not push that point. I’d ask them to come up with other ways to tell if they are on track for the sprint, and to be able to collaborate more.

An idea for telling if they are on track. Ask each team member in the standup how confident they are they will meet the sprint goal. 100%, 90% etc. Track this each day. If it starts to drop you have an indication that something is wrong. I think this can be as effective as a burndown. Another alternative if you really want a burn down is simply to count the number of tasks still to be done on the board rather than adding up estimates. It will also give you a trend. Both are these are just some ideas to help you see there is not just one way to solve the problem. The real trick is to figure out what problem you are trying to solve, if it needs solving, and then to engage the team to solve it themselves, rather than trying to solve it for them.

Another technique you might find useful is to decompose tasks as you work, so anytime a task is in progress for more than one day ask the team member: what did you finish yesterday (that can be a task in done), what are you busy with today (that can be in progress), and what won’t you get to today (that can be in to do) and someone else can pick it up. If they struggle with this level of decomposition, then it is probably a warning sign of something else, like maybe a trust issue preventing transparency. Having said that I have to agree with some of the comments that the focus shouldn’t really be on tasks. Take a look at my previous post on breaking down stories to see if you can get smaller stories. A goal I like to set for the team is a cycle time of 2 days per story. i.e. can they go from starting to completing a story in 2 days. If you can get this right, you can burn down story points and you will stop worrying about tasks :)

On to Scrum Puzzle #5. You track the team’s velocity over time, to help the Product Owner plan releases. After 6 sprints on the current release the Product Owner comes to because he has noticed that the team’s velocity is dropping each sprint. 6 sprints ago it was 50 points per sprint, and now it is only 30. He is concerned that if the trend continues the team will soon be delivering nothing at all. He wants you as the Scrum Master to talk to the team because he needs the velocity back at 50 if you are to meet the release commitments he has made to the stakeholders. What do you do… (or should that be what did you do, because I know this happens out there!)

About these ads
2 Comments Post a comment
  1. marmil #

    Is there a problem that the velocity has dropped? can the team identify it – then it needs to be solved. Also i could think it would be helpful to maybey break down some stories further to get some clearer estimation- (re)estimate the backlog items and adjust the scope according to the more granular stories.

    Does every story need to be completed.? I would explain to the PO that sometimes less is more. it is the team that decides how much they can do in the sprint. If we the team should overcommit the commitments will surely fail. The most important thing though is that an estimation is an estimation. A release commitment is not written in blood. I would explain this to the PO, that he/she will get what is most important. Adjust the scope if it does not fit the timeframe.

    December 16, 2011
  2. Wanting to velocity to be 50 again reminds me of a story of friend of mine’s wife, she wanted the plane to fly faster to JHB so that she could catch her connecting flight. Not really possible. especially if you do not know all the influencing factors.

    I think this comes down to a trust issue between the po and team, As the Scrum Master what can you highlight to the PO has changed over the last few sprints, has the team continuously improved? has the definition of done changed? Has the team gone through another F,S,N,P phase.

    Finally at the review the team is demoing work that is delivering business value and meeting Done.

    The Scrum Master should facilitate the Po to re communicate the release plan based on knowns and empirical data back to stakeholders and achieve a level of understanding why the velocity has decreased in the team.

    December 19, 2011

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 44 other followers

%d bloggers like this: