Do No Sprint Harm
Creating a test sprint or varying the length of a sprint might seem like helpful ideas to address common problems on agile projects, but they should be avoided at all costs. These anti-patterns won’t fix the real underlying issues; in fact, they will probably exacerbate them and weaken your team.
In the first article of this series, we introduced the concept of anti-patterns in agile project management; that is, common solutions to common problems that rarely or never work. Since then we have described nine such agile anti-patterns and links to each article in the series can be found at the end of this latest installment. The resulting reader comments show many people are recognizing their own projects and teams in this series. Discovering that our peers have experienced similar issues can be a turning point on the way to Agile success.
Agile Anti-Pattern #10: Creating a test sprint
One of the novel aspects of Agile, and of Scrum in particular, is that all the work is supposed to be accounted for in the “definition of done.” This means that a story isn’t considered complete until it is properly tested, released, documented and supported. An untested, unreleased or undocumented story simply isn’t done, and should continue to be added into sprints or iterations for completion.
Many teams, particularly teams new to Agile,
Please log in or sign up below to read the rest of the article.
|
"You do not really understand something unless you can explain it to your grandmother." - Albert Einstein |




