Reducing work in progress - should anyone really pick up any task?

Question

I'm in a Scrum environment, and we get feedback from the PO that all stories should be closed that are currently in progress before bringing in more stories. The goal is reducing WIP and getting stories accepted, which is a good goal. But would it really be wise to have, for instance, a DBA run a manual test script in order to close a particular story, when the part timer who does various "grunt" tasks will be available tomorrow? It seems this is the direction our PO wants to head in, but seems inefficient to me. What happens is that tomorrow the part timer is available, but there are no tasks for them, the only outstanding ones being "above their pay grade".

So it seems like a tension between reducing WIP and yet having people work on things that "make sense". Do you find its better for the team to have anyone work on any task? Or do you keep work open longer in order to have certain people do what they do best?

Answer 1

The reason for limiting WIP is to help work flow through the system more quickly. This lets you get feedback on whether the work you're doing is valuable. The learning could come from showcasing it, from putting it through the build, from deployment, etc. This learning could play into other, upcoming work, too.

The longer work hangs around without getting this feedback, the more chance you'll be creating work which you'll have to undo, later.

This is why the DBA should pick up the script task - not just because we want to close the story, but because we want to get feedback on it quickly, rather than waiting and starting something else which might be waste. Your part-timer can then pair with more expert developers the next day, which will help him raise his ability (and his pay-grade) so that he can help the team more effectively in the future.

Answer 2

It's much easier to say "yes, anyone should pick up the next task" when your dealing with a group of generalists. As soon as in bring a specialist (and a DBA is definately a specialist) it becomes more a question of what works for your situation and team.

If the DBA more like a DBA/programmer than he probably should pick anything up. However I would also have others (nonDBA) pickup DBA cards. This allows more than just one person to gain experience with a particular area. I would also have the person working the card make sure to communicate/consult with the DBA (or whomever is the domain expert) for any card they pickup.

Answer 3

I've been trying the AgileZen.com project board. You can set a limit on different stages. For my personal project, I've limited the 'In Progress' stage to just 2 stories (limited attention span). A story could be 'In Progress' and then get moved back to 'On Deck' if you need to move another story to the 'In Progress' stage, but you don't just do any kind of half-baked work-around to move it to 'Completed'. Seriously, you want to reduce WIP without doing quality work? It can be tough to do both and someone should be pushing for progress, but there should't be so much incentive that quality is sacrificed or time is wasted.

I guess if the DBA in your case just has nothing else to do but fool around with a manual test script, why not? Consider it as a learning experience. Worse thing that can happen is the part-timer comes in tomorrow and does it all over gain.