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 started using Scrum a few sprints ago. Our project involves building software interfacing with physical devices (think robots and sensors) and our typical Product backlog usually represent adding controls device to the whole system.

We split down the task close to the example here. Each device integration feature is split into code, tests, integration tests, peer review, etc. Obviously, there is a sequence inherent to each Product Backlog Items. Typically, our sprints last 2 weeks and the team has between 4 to 6 members.

We run into 2 problems at the end of sprints:

  • The first is to keep everyone busy at end of sprint.
  • The second (related) one is contention on system. We pretty much end up integrating during the last few days of the sprint. We only have one integration system, so people are often blocked from continuing to work on their task because they can't access the system. Since it is the end of the sprint, there is not much work left to do in the sprint backlog. What should these people work on? Pick up items from the top of the product backlog is not well received from the product owner, since the current items are not done. Working on technical debt will help the project as a whole but won't help completing the sprint.

Are there any best practices to either structure sprints to avoid these issues? Tips to negotiate with product owners?

share|improve this question
3  
The phrase "Continuous Integration" comes to mind. –  Robert Harvey Jul 15 '11 at 17:02
    
Continuous integration is what the integration system does all by itstelf once integrators integrally integrated each device on it. Unfortunately, with our setup, it is not as simple as checking the code in, we need physical connections setup with motors and I/O Cards and what not. Making sure your new device runs in the CI environment is a task itself, and that is the task causing contention. Interestingly enough, taking whatever is on the CI system and putting it on the real machine is a rather trivial process - proving that CI is worth it. –  Vincent Hubert Jul 15 '11 at 20:09
add comment

migrated from stackoverflow.com Jul 15 '11 at 16:57

This question came from our site for professional and enthusiast programmers.

4 Answers

in some ways it's good that your slow at the end of a sprint, the means your estimating well and not over committing, as far as keeping busy, on scrum teams I have worked on we always added research tasks for what's coming up next sprint.

This could be doing proof of concepts for things that are coming up, or looking at where to refactor existing code, working on getting better test coverage on your code, etc.

share|improve this answer
1  
Fixing bugs was another task that kept us busy at the end of the sprint. –  Sjoerd Jul 15 '11 at 20:25
add comment

You should fix your integration system so your team can integrate their work as soon as each task is complete, rather than waiting for a big bang at the end of the sprint.

I recommend working with user stories short enough to be finished in a few days. Finished here means code complete, tested and integrated.

share|improve this answer
1  
Actually, integration can be done on the system at any time. The issue is that there is nothing to integrate before the tasks are at integration stage, and most arrive at that stage near the end of the sprint, hence contention. –  Vincent Hubert Jul 15 '11 at 19:48
    
Seems my recommendation about making your tasks shorter would help here, no? –  Martin Wickman Jul 15 '11 at 19:51
add comment

Wow, if you didn't say robots, I would assume you were on my team right now. We have the exact same set of problems. Having worked on numerous agile projects with varying degrees of fidelity to the manifesto and varying degrees of success, my analysis is that our problem is sprints being too short. We are doing two week sprints which causes a few problems. One is that we end up being overcautious in planning and frequently end up with dead days at the end. Second is the huge overheard of review, retrospective and planning taking up 1-2 days out of every two weeks. Another is, like you said, having to integrate at the last minute and frequently failing hours before the review. My first and most successful agile project had four week sprints, which I gather is pretty huge by industry standards, but it worked great for us.

EDIT: Remembered one more thing from that first project that was a boon. We always had a fully prioritized product backlog and gave developers freedom to grab tasks off of it if their sprint tasks were complete and no other sprint tasks were available.

share|improve this answer
add comment

Remembering that it is the entire Team's responsibility to deliver, not individual members, per se, is it possible to have all four-to-six members work on each task TOGETHER--push each one through the process and move onto the next. This might sound inefficient at first, but if the bottlenecks you are seeing are that bad, it may be a valid option.

Also, you might want to look into the theory of constraints (Goldratt's The Goal), and see how you can best analyze why and where you have these integration bottlenecks.

share|improve this answer
add comment

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.