Agile Development At Full Stretch
by Kelly Waters
In my experience, most developers are over-optimistic and tend to under-estimate.
However it's not uncommon for some teams to estimate on the cautious side. If you find yourself in this situation and finishing the Sprint (or timebox) early, include a couple of nice-to-have "stretch tasks" (or features/stories) in future Sprints.
It's important to specifically identify them as stretch tasks, i.e. "could haves" in MoSCoW terms (Must-have, Should-have, Could-have, Won't-have). Make sure no-one is ever beaten up if no stretch tasks are ever achieved in the Sprint. By contrast, do make sure you celebrate as a team if you reach any stretch tasks - even if it's just a lot of back-slapping and self-congratulation!
And don't forget to apply the same rules to the stretch tasks as everything else; they must be 100% complete (i.e. shippable) to count.
10 Key Principles of Agile Development
18 January 2008 21:41
I'm torn, should "could-have stretch tasks" for this sprint be the "must-have" (or at least "should-have") stories in the next sprint's product backlog? I ask because what if the team has time to start the "stretch task" but can't finish. (To prevent the unfinished task from being muda) the team is commited to completing carried-over unfinished "stretch tasks" first, which could interfere with priorities OR should "stretch tasks" all be tiny and available irregardless of priority?
19 January 2008 16:51
Keep stretch tasks small to try to avoid this problem.
A stretch task could be to complete something that helps with the next sprint - to get a head start.
Or it could be an important research, training or documentation task.
If it's new code, and there's a chance it can't be completed before the end of the current sprint, I would advise you not to include it in the build until it's confirmed as correct, so you don't miss your sprint goal over a stretch task.
Kelly.