Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My team does 2-week sprints, and the trend we've identified (which we want to move away from) is that our daily standup scrums are relatively straightforward early in the sprint, but then transform into a more frantic scramble toward the end.

The first week developers are heads down in coding, analysts are developing test plans and answering developer questions, and testers are refining existing tests and identifying areas to test (but not necessarily testing just yet since there isn't as much out there actually ready to test). Blockers and scope creep tend to emerge into the second week, and then as we see how close we're getting to the end, we force ourselves to make tough choices and be more communicative.

How can we "spread the wealth" and increase the overall "tempo" (I guess?) of our scrums from the beginning of the sprint to the end?

share|improve this question
    
How long are your tasks? Do people stop working on a task and work on something else in the first weak? –  Euphoric May 9 at 16:26
    
The tasks vary pretty widely in length. There will be a few 2-3 day tasks, and many that take half a day or less to code and test. People will generally work multiple tasks in the first week as time permits. Frequently the testers are in a holding pattern of sorts near the beginning of the sprint until something comes up ready to test, but that's increasingly becoming the exception rather than the rule. –  Darth Continent May 9 at 19:05

3 Answers 3

Your problem looks like the typical "waterfall in each sprint", if you do the real testing in the second week the problems appear in the second week.

In my experience there are various areas you can improve:

  • Make small user histories, one or two days per history perhaps, this way at the end of the first week you have some US completely developed and tested.

  • Revise your technical practices. Agile don't work only with post-its, the team its using properly techniques like TDD or continuos integration? (this two are fundamental for checking assumptions earlier in the process and don't have this "at the last moment all problems emerge" symptom).

  • Your talk about analyst, testers and developers, looks like a lot of specialization. This its not bad in itself, depend in a lot of factors, but perhaps you need to do something to improve the communication from the first day of sprint, for example try developers pair with business analyst or testers.

And the most important: use the retrospectives to discuss this problems, what the team thought?, what solutions they propose?. At the end of the day your solution its inside your team not in stack overflow :P

share|improve this answer

Blockers and scope creep tend to emerge into the second week

Oh, Hell No! Stop the sprint immediately. This will not stand. Product Owners need to understand the consequences of interrupting a sprint. We have to start all over.

Find out if there was a way to avoid this problem (Did we missing something.). Go through the start of a new sprint. This will smooth out the "highs" in the project so afterwards everyone won't feel so low. Smooth and steady. No panic. No death march every 2 weeks.

Standups - I don't care if you had your head down in code all day yesterday, what did you do?, what are you going to do today? It's not fancy and no need to be entertained. Stay awake everyone for 15 minutes - it's not that hard. Everyone should still be jazzed-up that they had to redo the sprint.

Just because they're called sprints doesn't mean the project isn't a marathon.

share|improve this answer

You seem to have a number of dysfunctions but here are two that I'd look to address early:

Your original question gives me the impression that you're working as a group of individuals. The analyst does their bit, passes it to the developer who does their bit before passing it to a tester ... and so on. Scrum needs cross-functional individuals, not silo'd specialists.

Scrum teams focus ruthlessly on moving a single product backlog item to done. It doesn't read like this is happening with your team. The late announcement of blockers and emerging work gives me the impression that you're running a mini-waterfall where all the testing is being left to the end.

So, based on my assumptions, here's my advice:

  1. Encourage cross-functional skilling in the scrum team. There's no reason why a tester can't help with analysis or a software developer can't help with testing, etc. The team does the work that's in front of them and needs doing.

  2. Reduce Work In Progress (WIP). Focus on moving one product backlog item to 'done' before starting the next one. Yes, sometimes that's silly because you have people stepping on each other's toes so try this simple guidance: The amount of product backlog items being worked on simultaneously must be no more than half the size of the team.

share|improve this answer
    
maybe scrap Scrum and go to a more Kanban approach might help them.. or everyone for that matter. –  gbjbaanb May 14 at 7:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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