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.

We are running 2 weeks sprints where the team will just barely finish development by the last day of the sprint but cards are not complete because testing is not finished. The definition of done is really "when development is complete" rather than "when the stories are complete." We have a 1 week delay between the last day of the sprint and the release date. The team does finish the sprint by the release date but that seems like that isn't quite meeting the objective of scrum. The team starts the next sprint the day after the previous sprint ends.

I see the following problems:

  1. team is not using whole team testing
  2. team is not too interested in pair programming or piling on one card at a time.
  3. Maybe the stories are too large and we should break them down more so that we finish at a more steady pace throughout the sprint?

Any suggestions on how we get the team bought in to finishing the sprint by the end date? Or other ideas?

Why do we think it is important to finish by the last day? Why does it matter if the team is still finishing by the release date? (I have my own answers but am curious what others think here.)

share|improve this question
3  
wow. Two things. 1) Done means done. Done coding, testing, ready for prod. Revisit what you consider "done." 2) To answer your title question, it's always important to estimate well. Your teams are NOT working on new stories if they are still fixing the previous sprint prior to release. Your estimates will never be right if you are always working on things from the previous sprint. –  Steve Miskiewicz Apr 19 '12 at 3:13
    
adjust how many new stories you are taking on in new sprints to reflect how many you did last time. and yes done needs to mean done else you are just lying to your selves. –  jk. Apr 19 '12 at 12:51
    
So, you call software done before it has been tested? There's your problem right there. –  Bryan Oakley Apr 19 '12 at 23:45
add comment

migrated from stackoverflow.com Apr 19 '12 at 11:09

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

2 Answers

Where I used to work, we'd have a code freeze to allow time for testing in the sprint. This also would give developers time to do refactoring and other minor tweaks while QA reviewed the work done to see what is and isn't ready for production as the refactoring work wouldn't be merged until after the release was tagged/branched.

I'd question how well does the team understand the idea of velocity where X points of story work are done in a sprint and not bleeding into another sprint with bug fixes or other work that would impact the next sprint's work.

share|improve this answer
add comment

The need of Scrum isn't to complete every story at the end of every sprint. In fact, that might not happen, especially early in a project when you are still settling on a velocity. The idea is to have a potentially shippable (working, tested, and documented) product that adds business value to the customer at the end of every iteration.

The first thing to do is to improve your definition of done. Done should mean that the story is complete. That means it has been designed, implemented, unit tested, integrated and passed system and acceptance tests. When a story is done, that means the feature or capability that the store represents is ready for delivery to the customer. The Scrum Alliance has some articles on what a good definition of done looks like, how to know when you are done with a story, and a methodology for creating a good definition of done.

Next, you should probably begin to work on your estimation and planning. It shouldn't be a continual struggle to incorporate the stories into each release. It begins with having appropriate and accurate estimates as to the size of the story, which often uses story points to provide an estimation of the relative effort required to complete the story. Once you have estimates, you need to use these estimates to plan. If you find yourself finishing 10 story points every sprint, don't pull more than 10 story points into the next sprint. If you pulled 10 story points into one sprint, but only finished 8 of them, only include 8 in the next sprint. If you finish early, you can either pull in more story points or use the additional time to reduce technical debt by refactoring, writing new automated tests, or improving existing tests (as a few examples).

Rather than starting the next sprint immediately, make sure you have time for your retrospective and planning meetings. Use this as an opportunity to determine what was problematic or needs improvement, and then implement corrections for the process in future sprints.

I think that doing this will resolve some of your problems, and make others easier to fix, or at least bring out more information. Some of the problems are also related to organizational culture, such as the entire team participating in testing or not using pair programming. Eventually, you are going to want to get the entire team into testing (and other activities), since Scrum is centered around a team that has cross-functional skills. Improved estimation will also help you identify if your stories are too large. As far as pair programming - it's a non-issue, since it's not required for Scrum and might not be of use to your team.

share|improve this answer
add comment

Your Answer

 
discard

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