Is it bad practise to work on multiple stories concurrently? [closed]

Question

In a scrum team, how important is it to complete a single story before moving on?

Our scrum master is fairly dogmatic about bringing a single story to completion before moving on. I can see that development would appear to be more "controlled" in this scenario, plus the scrum master would have a very accurate picture of what team members were working on at any given time... but I am interested in what this really buys us?

Clearly the scrum master wants to minimise divergence of the burndown from reality to avoid a shock come the end of the sprint - but surely if the sprint is two weeks long, the burndown is updated consistently and blockers are communicated at standups - any such divergence will be constrained by the sprint length, and be made visible mid-sprint through the usual channels (i.e. the standup or speaking to the scrum master individually). Any remaining issues can be dealt with in the fortnightly retrospective.

The reason for the question is that I seem to find I work most efficiently by keeping say 2 (or 3 if one is particularly easy) stories in progress at any given time which I work on as I see fit. This seems to assist with the sub-conscious background thought that assists with completion of the task. It also permits me to better understand the bigger picture if a couple of stories are related.

Our stories usually work out to be one or two days worth of work.

So, is working on a couple stories at a time frowned upon and if so what does one-story-at-a-time buy you?

Overlive

I'm voting to close this question as off-topic because it is not about programming. – Vaish

Answer 1

i think it really is up to the team to decide. i think you hit it in your write up about the burndown, the most important thing is to meet your sprint commitments consistently. how that happens really should be up to the team if they truly are self-governing. the team im on now, our norm is to work on multiple stories at once; its the nature of our setup given that we try to really spread ownership of stories across the team. it may be a different norm for yours if you have shorter stories and more of a individual ownership style.

Metapsychology

Answer 2

I personally think one story at a time works well because it keeps you focused on a task. The cost of context switching between multiple stories can be high. This is a personal preference for me, but different people work differently. Though I think your scrum master is correct in his methodology, if you've found very compelling reasons for multiple stories at a time and can demonstrate that it is in fact helping progress, that would be a good case to make.

Juieta

Answer 3

IMO, there is an underlying question here. Sometimes when working on a story, I'll need something from another department/team,e.g. clarification on a requirement or a graphic for a page, and this means that I won't finish one story before moving on to another story. While you do mention this in discussing the blockers at standup, this can happen where it is up to someone outside to help me finish a story so there can be multiple ones on my plate. Thus, I can have multiple stories due to blocking on something and still wanting to be productive.

In general, I don't like trying to manage multiple copies of the code base or switch my code a lot, so I prefer doing one story at a time, assuming no blockers. The size of the code base I'm working with is ~1.1 GB of data spread over 82,000+ files so having multiple copies could be more than a little painful I'd imagine.

My personal guess on this is that it is up to the team to set the standard and see that it works for them. If some like one story at a time and others do multiple and all is well, cool. If everyone likes having multiple stories at various points of completion, that can work too.

Jordaens

Answer 4

I generally would think that the decision on how to work best should be made almost exclusively by the team. The ScrumMaster's role is to help and support the team, not to question the team's way of working during a sprint.

To be fair, sometimes it can be a good idea for the ScrumMaster to point out possible flaws or risks - that would fall in the category "help and support". Being dogmatic about your personal idea about how a sprint should look like internally is not something I would want a ScrumMaster to act like. It sounds a bit like misunderstading the role as a manager's role, which is simply not the case.

As for how we do it: We almost always work on several stories at once. At the moment we're having a four-person scrum team with three developers and one tester and we nearly always have at least two or three stories going at the same time. In the last sprint we tried to start with all stories early in the sprint to get to the point where we have a basic design and a good idea about what the potential problems could be. Of course we were not working on all stories at the same time after that.

I understand that in terms of risk-management you might want to make sure that everything is done for one story before you tackle the next. However, the disadvantage is that when you run into unforeseen problems lateron, you might not have enough time to fix those. Usually problems show their ugly faces during the implementation phase and often enough quite early. So, you basically exchange one risk for another.

Which risk is easier to handle shoud be up to the team. It's their sprint after all and while I think it's perfectly fair for the ScrumMaster to mention concerns about the way the sprint is going, he shouldn't force his idea of the best way to work on the team.

In the end, I think it boils down to these two things:

1. YES, we do work on several stories at once and it has worked out fine so far.

2. Remember that the ScrumMaster is working for the team, not the other way round.

Please note that I'm mostly talking about the whole team working on several stories at once, not one developer. The problem I'd see there is that you need to make sure that you don't block any stories by keeping them open, so that no-one else can continue the work. Once again, this is a question of circumstance and preference. When it comes to testing, our tester often has a couple of testing tasks for different stories, so that he can easily switch to a different task, if some bug blocks him from continuing testing a feature.

Sorcha

Answer 5

Don't hog the backlog... In my experience, when stories are between 1 and 2 days in size, they tend to be implemented by a single developer. If you are working 2 or 3 stories concurrently, that might reduce the amount of things in the backlog that other developers can pick from and jeopardize the sprint.

... but plan for blockage On the other hand, working 2 or 3 stories at once means that if you are momentarily blocked on one story you can be immediately productive on the other. I find that there's some overhead each time I start a new story. This overhead makes it hard to fill an hour long "gap" in my day with a new story, whereas it's much easier to context switch to a story I've already started.

Bottom line, let the team decide... and then review results during a retrospective. If your stories, tasks and work process support an environment where team members can work 2 (maybe 3) stories at a time without sacrificing productivity or predictability, then your SM should respect that. But at the same time you should honestly review the results during each retrospective and be prepared to change if the SM doesn't think its working.

Osorio