-1

So today I was managing my team and they are in the middle of a sprint, I went over to my dev team just to find out how they are getting on. Turned out that one of my developers was waiting on his colleague to finish his side of the story before beginning work. In the mean time, he was working on items in the backlog out of his own accord, since the rest of items in the sprint required his colleague to completed before he could intervene.

When this happens, should you add items from the backlog into the sprint for the developer to complete during the time he is waiting for his colleague to complete his side of the work? Or should you let the developer freestyle?

  • Depends... I would have that developer pair with the person implementing the work he's waiting on, or review some code, or run the manual tests. There are lots of things a dev could do, but it depends on your system. Is this Scrum or Kanban? – RubberDuck May 10 '16 at 16:26
  • We are running scrum currently. – bobo2000 May 10 '16 at 16:36
  • I would get more information about the nature of the dependency; because you can almost always mock up the dependency to continue working. For example, he could write his code in the TDD mindset; in which he would be mocking up the dependency in his tests and the tests could then verify his code. – drneel May 12 '16 at 14:54
3

When a developer is blocked it can be tempting to bring work in to the sprint from the backlog.

Before you do this, consider the following:

  • Does the story coming in only require development effort? If it requires other activities, such as testing, then does the team have the capacity to complete the new story? I have seen many instances where work is brought in to a sprint to keep developers busy that then ends up overloading the team tester.
  • Does the story coming in impact on the team's plan for the sprint? Perhaps the team has worked through how they want to handle the stories for the sprint and the new story will require a rethink of those plans.
  • Is the Product Owner aware of the new work being added to the sprint? Perhaps they have recently been rethinking that particular story or maybe they want to prioritise something else instead.

There are a number of alternative uses of the developers time if they are blocked:

  • The developer could pair with the person they are blocked by. This could speed up completion of the story and may also share some knowledge to prevent future blockages.
  • The developer could look to help out other members of the team.
  • The developer could write some automated regression tests and so improve the team's regression coverage.
  • The developer could do some quality improvements, such as running code quality analysis and fixing any issues.
  • The developer could start to review stories at the top of the backlog in preparation for backlog refinement and planning sessions.

Finally, I would discuss the situation in the retrospective. Did the team anticipate the dependency between developers in planning? Is there a way to avoid this situation in the future?

  • @ Barnarby Golden it is getting to a stage where a lot of stories have dependencies. I have told the dev team that the only time they can take on new stories from the backlog during a sprint is once the sprint backlog has completed ahead of schedule. Is this the correct way to do it? – bobo2000 May 11 '16 at 9:35
  • 1
    You might want to take a look at the INVEST mnemonic as a guide to writing stories: en.wikipedia.org/wiki/INVEST_%28mnemonic%29 This emphasises the need for stories to be independent. – Barnaby Golden May 11 '16 at 9:44
  • 1
    Deciding to bring new stories in to the sprint should be a team decision and should involve the Product Owner, Scrum Master and development team. I don't think there should be hard-and-fast rules, but that there should always be an open and thoughtful discussion before doing it. – Barnaby Golden May 11 '16 at 9:46
2

It sounds like your development team is working the way it's supposed to work. The dev who is blocked has not been idle, he's grabbed work from the backlog. No real worries at all.

Ideally, this story dependency should be caught in the Sprint Planning meeting. At that time, the blocked dev could be assigned backlog items in anticipation of the wait. The planning metric to watch in this case is the overall points total for the sprint, and how many story points both of those devs are assigned.

If this dependency was discussed in the Sprint Planning meeting and an appropriate level of points assigned to each dev, then I would guess the blocking story is taking more time (points) than originally estimated. In this case, your dev team is still working as it's supposed to. Some stories may potentially get dropped because this blocking story has grown.

The last possibility is the dependency was discussed, the appropriate level of story points assigned to the devs, but the dev working the blocking story has been side-tracked onto other (higher priority) tasks. This situation requires the scrum master to step in and re-balance stories and priorities to keep the work moving along.

All in all though, it sounds like your agile dev team is working it out.

2

Scrum Team Members Aren't Individual Resources

When this happens, should you add items from the backlog into the sprint for the developer to complete during the time he is waiting for his colleague to complete his side of the work? Or should you let the developer freestyle?

Neither. Your process needs to stop thinking of developers as individual resources. Instead, the Development Team is collectively responsible for the stories accepted into the Sprint in support of the Sprint Goal.

Never Pull Product Backlog Items Unless Sprint Backlog's Empty

In the mean time, [the blocked developer] was working on items in the backlog out of his own accord, since the rest of items in the sprint required his colleague to completed before he could intervene.

100% utilization is not the point of agile processes, so the question shouldn't be whether the developer was busy, but rather whether or not he was contributing in a sustainable way to the team's overall effort. Working on other work already in the Sprint Backlog while waiting for a prerequisite task to become unstuck is certainly one viable option, so long as it doesn't introduce task-switching overhead.

Another option is for developers to combine resources to complete stories that require more effort to complete. While Brooks' Law may still apply in some cases, on a small team it can be very helpful to do pair programming or collectively swarm over stories to reduce work-in-progress.

No matter how you approach the situation, under no circumstances should you be introducing new work into an incomplete Sprint. This is an anti-pattern based on notions of individual productivity and idempotent tasking, neither of which is relevant to a well-run Scrum implementation. All work should come from the Sprint Backlog until the Sprint Backlog is empty or the Sprint Goal has been met according to the Definition of Done.

0

Introduce pair programming or swarming to your team, as CodeGnome already mentioned. This helps getting items finished, before starting new ones. Also the team members can transfer knowledge, which is very important.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.