Sprint, Jog, Sprint
Since starting with scrum, we’ve always done consecutive sprints. Two weeks of coding (Monday-Friday for the most part) near the end of which we do activities like estimating, planning, sprint review, retrospective.
We’ve reached a point where, for a variety of reasons, that doesn’t feel right anymore. Reasons include:
- The product is released and fairly mature. Coding work includes a lot of tweaks, enhancements, bug-fixes in addition to new development.
- Planning and estimation feel rushed. Applying arbitrary time-boxing to these activities doesn’t feel right when a little extra chat / research can prevent nasty surprises during the sprint.
- We don’t seem to have any proper time or place to help stakeholders develop simple requests for functionality into reasonable user stories that can be estimated.
So we’ve adopted a new practice: A week between 2-week sprints that we’ve called (after going through some flippant alternatives) jog week.
So now the pattern is something like this:
- Product owner meeting works on the backlog every Tuesday. (During sprint weeks this is mostly adding and reviewing new stories with stakeholders, during jog week it’s primarily prioritisation)
- Developers do estimation on every Wednesday (jog or sprint) for an hour. We seem to get through maybe 8-12 stories in that time.
- Planning (including tasking user stories) takes place on Thursday of jog week.
- Sprint Review takes place on the last day of the sprint
- Besides the above, the rest of jog week is taken up with bugfixes and ad-hoc technical requests, helping stakeholders develop user stories to the point where they can be estimated, refactoring, reading coding/agile blogs, etc.
We’ve still got to work on the details, but based on the two jog weeks so far, we’ve got more than enough to fill up that third week.
June 11th, 2009 at 10:44 am
Andy,
Why not do 1 week sprints? It looks to me thats what you are doing in practice anyway, just under a terminology of sprints and jog weeks. With 1 week sprints, you can look at the backlog every week, decide whats important at that point in time, schedule it and work on it for a week. Besides should any urgent request come through, you only have to wait a maximum of 7 days to pull it in.
June 11th, 2009 at 1:18 pm
The urgent requests typically won’t wait for anything like as long as a week. Actually ‘ad hoc’ is a better term than ‘urgent’ and these things fall into two categories. (1) Support requests (the team functions as dev AND 2nd line support) (2) emergencies (e.g. site is down, or a show-stopping bug has been exposed). It’s all down to a single team having both an operational and a tactical focus. Even a 1 week sprint would get interrupted.
We’ve adopted Kanban (temporarily at least) to help fully expose the issues, and once we have a solution for the issues (more devs ? separate 2nd line support team ?) then we can probably go back to sprinting.
Andy
August 29th, 2009 at 9:56 am
[...] Ones and Threes » Blog Archive » Sprint, Jog, Sprint http://www.onesandthrees.com/2009/04/sprint-jog-sprint – view page – cached Since starting with scrum, we’ve always done consecutive sprints. Two weeks of coding (Monday-Friday for the most part) near the end of which we do activities like estimating, planning, sprint review, retrospective. — From the page [...]