Category: sprint
Introduction
I may have blogged about this previously. I have written so many blogs, I can't recall any more. However questions regarding Sprint length surface on the forums regularly.
As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.
The Context
A team of 5 members currently working with 10-day sprints. They haven't managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.
Bookmark/Search this post with:
At the end of the sprint, the Product Owner, Team
and Scrum
Master meet to review the progress of the sprint. The product owner has
to
evaluate the state of the project so s/he can decide what to do next.
How does
the Product Owner ensure that s/he gets a complete and correct
understanding
about the state of the project, including all inconvenient truths? Here
is a
simple agenda/meeting template to follow, to make sure all the bases
are
covered.
Last week, I introduced that concept of a Sprint
Contract to
define the parameters of the sprint. The factors Scope, Quality, Time
and Cost
will be familiar to any project manager. Scope is defined by the
stories and in
particular their size. Quality is defined primarily by the definition
of done.
Time is fixed by the sprint duration. An upper limit on the costs is
set by the
team size * sprint duration, after adjusting for absences and other
tasks.
A simple sprint review needs to
- Confirm that the team has delivered on its commitments
- Confirm that the overall project is on track
- Examine the functionality which has been delivered.
Bookmark/Search this post with:
At the beginning of each sprint, the Scrum team
and product
owner negotiate the scope of the sprint. They have a limited amount of
time to discuss
and agree on the sprint backlog. The product owner wants functionality
implemented properly and to invest development dollars wisely. The team
wants a
mandate it can fulfill. And everyone wants the meeting to finish on
time! Here
is an agenda (complete with a downloadable template) to follow so that your sprint planning will be successful.
Bookmark/Search this post with:
As we get closer to the holiday season, external factors threaten
to disrupt the sprint rhythm. People go on vacation, sprint meetings
fall on or between the holidays, and company events pull the team
away from project commitments. At the same time, the pressure rises
to get affairs wrapped up by the end of the year. It’s time to
get that release out, time to close that deal, time to define the
next version.
Here are a couple of tips to help you
get the through the holiday season with a minimum of additional (job)
stress.
Bookmark/Search this post with:
The adaptation mechanisms built into the Scrum process allow for many modifications and adjustments in the sprint planning procedure. Different variations work for different teams and environments. Here is one of the variations that I find useful:
Preconditions
Product backlog contains a set of user stories sufficient for at least 2-3 sprints, ideally - for the whole current release and more. The team together with the Product Owner and possibly with some stakeholders went through the top stories 2-3 days earlier. As a result for a sprint or two there are enough reasonably small and well understood top priority product backlog items.
Advertisement:
Bookmark/Search this post with:
Scrum is an agile software development process with a high focus on the project management level. It has a concept of a sprint review in the end of the iterations, where the product backlog items taken into sprint (and possibly the whole sprint) are accepted or rejected. It is possible and even recommended to accept or pre-accept some items already during the iteration, but it is not mandatory and is not always possible.
During sprint review Product Owner indeed can reject the content, because the team got him wrong, perceived quality is low, some old features got broken or team simply did not have enough time to finish everything it was hoping to deliver. Then what does the rejection mean? Isn't it a bit too naive to expect the people disappointed by rejection deliver better during the next sprint? Isn't it easier just to add some "fix tasks" to the backlog?
Bookmark/Search this post with:
There are not that many people who like micromanagement. No surprise that the fear of day to day micromanagement scares some people off the agile processes. That is not the only way agile processes can look micromanaging. All the agile processes employ the idea of iterative and incremental planning on pretty much every possible level. Scrum Product Owners can change the project priorities every 14-30 days, in Extreme Programming, the usual iteration length is just one week. Naturally the possibility for the rapid shifts in the priorities can make it difficult for the team to design and build a good architecture and work at a full possible speed.
Bookmark/Search this post with:
Update: Link to XLS fixed. Kudos to Jukka Laurila
Bookmark/Search this post with:
Some teams using Scrum and XP tend to have special Q&A iterations every several iterations and/or before the release. While it might be ok, during the transition to the agile processes, as a rule of thumb having Q&A sprints is a good indication of the problems with the definition of "done". The main point of iterative development is to have a "potentially shippable" product at the end of iteration. Planning for Q&A sprints essentially means that at the end of the iteration, team does not plan to have a potentially shippable product.
Bookmark/Search this post with:
Bas Vodde collected and published examples and templates of the Scrum product and Sprint backlogs. Most of them are in MS Excel format. Some (XLS) include a lot of comments, some (XLS) are very colourful. Check them out, Excel can really cover most of the needs of the archived backlog tracking.
Cached templates
Here are the cached copies of templates that I reviewed on this website.
See Also
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle
