4

In the beginning of the Sprint we assign various items to each developers. Some developers may work on more than one item at a time, however when they work on the item they typically Start Progress which puts the item in the In Progress state.

In the concept of Scrum or Kanban, does anyone know negative consequences of having more than one item in In Progress state per developer?

2
  • 1
    Why do you care about tasks at all? Focus on value delivery and let the development team figure out the rest. As longas you hold them acountable for working software it's all good... Let the team decide. – MrHinsh - Martin Hinshelwood Apr 3 '17 at 5:54
  • We are held accountable for the working software and we let ourselves decide. Thanks for echoing the essence. – bhantol Apr 3 '17 at 12:01
10

Having more than 1 item In Progress for a single person will kill productivity. Multitasking is horrible for getting things done quickly and/or well. See Agile team full of part time developers for more details.

It might seem like a good idea to pull in new work if something gets roadblocked, however this is, in essence, optimizing for utilization (making sure everyone always has work to do) rather than for flow (making sure lead time, the amount of time issues spend 'In Progress', is as low as possible). Which is not efficient. See the 100% Utilization Myth for more information. In this situation, it's better for the Team to focus on removing roadblocks as quickly as possible, rather than leaving multiple tasks partially-finished and bringing about inefficiencies from multi-tasking and busy dependencies.

Also of note:

In the beginning of the Sprint we assign various JIRA items to each developers.

Scrum works best as a pull model, rather than as a push model. Meaning management (whether Scrum Master, Product Owner, or others) leave tasks in the 'TODO' column, and developers assign tasks to themselves once they finish what they're currently working on.

4
  • Offcourse you want multiple In Progress for the team. A single person might start an item but can't close it due to certain approval process at which point in the same Sprint have to resume work after review. – bhantol Mar 24 '17 at 23:31
  • @bhantol Updated your question to be more clear and my answer to provide more details. – Sarov Mar 24 '17 at 23:39
  • 1
    @bhantol No, of-course you do not want multiple items in progress for the team. The better they learn to work in parallel and complete a single PBI the faster they will be going. Minimize work in progress by swarming ( infoq.com/news/2013/02/swarming-agile-teams-deliver ). Also try to improve the approval process so it does not block completion of work. We moved the product owners into the team rooms to make sure they are always available and can approve as soon as the PBI is nearly finished. – Niels van Reijmersdal Mar 28 '17 at 5:28
  • 2
    Scrum does not work best in a pull mode. It's meant to work only in a pull mode, from the Guide: "They (the development team members) are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;" – mamoo Mar 29 '17 at 6:24
3

The main downside of having more than one issue in progress is a loss of focus (which results in loss of quality and efficiency). Another problem is that when people start to claim 'their' stories, the sense of collective ownership and team responsibility can get lost. From there it's just a small step to a team where Person X always does task Y, and that's not what you'd want in Scrum.

In general we strive for one story per person (and nobody is allowed to claim stories in ToDo until he can actually start), but there are circumstances when we allow (and even stimulate) someone to take up a few stories at the same time. Most of the time this happens when various stories share a common piece of code; from a technical perspective it makes sense to handle that part all at once.

2

There's something wrong in the context of Scrum. No task is assigned to a single developer in Scrum. The Scrum guide states:

They (the development team members) are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

It's a pull way of work, not a push one.

That said, and on to the specific question, it's a matter of making sure your board reflects in a consistent way the situation, so that you can take actions if something's not right.

Since "in progress" means "I'm actually working on...", and nobody is capable of working on 2 things at the same time, if you happen to have multiple tasks ongoing that means some tasks are waiting (for somebody to resume them, for external input, or are simply blocked)... so you either leave them in the "to-do" column, or you mark them as "blocked", "pending", "waiting for", whatever state is suitable given your internal processes. This way the issue becomes visible and can be treated.

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.