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.
