In my organization we almost never finish all the stories in the Sprint, and most of the stories are finished about 80%.
One reason for this, is that many times testers don’t have enough time to test all the stories, and developers don’t want to test. Another reason is that the teams are usually too optimistic so they commit to more than they can complete, and no one really cares about that, so they continue to do it each Sprint. Usually testing, bug fixes and last polishes remain on the task board after the Sprint is over.
The R&D manager believes that its not that bad to leave some bugs unfixed or to skip some non critical implementation, because then he can have usability test for the new features faster. Nevertheless I think he would be happy if the team could finish all the testing and bug fixes, but if not that’s completely okay for him as well, because there are always some stabilization (hardening) sprints at the end in which the smaller stuff will be taken care of.
I’d like to ask you, what do you think about this development method (which is not pure Scrum, but a more flexible/weak version of it).
Thank you.
3
It’s unacceptable to release untested work. There needs to be communication on what needs to be tested, how much time it will take, and how to know when everything works.
You say your team is using a Scrum variant. Are you estimating your stories? Are you testers involved in that estimation? Do you track how many points you actually completed beside how many you committed to?
The reason to use story points is to track velocity. That metric is supposed to be fed into the next sprints, adjusting the amount of work you commit to accordingly. If you don’t track completed points or don’t adjust future sprints using that evidence, you’ll either constantly be wasting time or constantly falling behind (which it sounds like you are).
My suggestions based on the information given are:
- Be sure your testers are involved in planning and agree with the story estimations
- Define “done”. The point of a sprint is to deliver a working, tested artifact. If you can’t in the time allotted, cut scope so that what is delivered is of good quality.
- Track your previous sprints. You don’t need many, just three or four iterations. If you find that you took on too much previously, commit to less this sprint.
0
- Things finished at X% (user histories are done or not done)
- Developers that don’t want to test
- People that don’t care about continuos improvement (making better estimations its continuos improvement)
- Stabilization sprints
For me this are BIG flaws in your actual process. I see the same or very similar problems a lot of times. One of the main benefits of Scrum its discover this flaws, when scrum make visible this problems there are two possible reactions:
- Try to find the root causes of this problems and improve your process, retrospectives and a critical (but constructive) spirit its key here.
- “Our world its different, scrum is some ideal thing that cannot be done, we need more flexibility.”… and nothing changes…
1