Sprint length
Hi,
Perhaps I am not able to use the search correctly. I expected to find some discussion to this topic but didn't found it. So I'm sorry if i just was too dumb.
We wan't to introduce scrum but we have some problems with the timeboxes found in literature.
Most sources advice a sprint length of 3-4 weeks. One problem is, that one of our niche strength is to react quickly on customer requests. And on the other hand we often have small projects that are shorter than 3 weeks.
So we have to go to a one week sprint (even 2 seems to long for us).
The problem is the overhead of the planning meetings, retrospective and so on takes away to much time from the week so that there are only 3-4 days left to actually work on the sprint. We tried but were not able to keep the planning meetings short enough.
On the other hand even in longer sprints I'm wondering about the time boxes for the planning meetings. Perhaps it is a problem of the level of detail, but I cannot imagine that it is possible to discuss with 5 or more people the work for the next 3-4 weeks in just 4 hours to a level of detail that enables to estimate it enough. And in planning meeting 2 there should be (as I understood) discussion of the team on even "how" the items should be done. The work for 3-4 weeks for 5-7 developers should be discussed on a "how" level in just another 4 hours? Even with 8 hours each I have problems to imagine that.
So I think I have not the right conecpt of how detailed the backlog items should be, and how deeply they should be discussed in each of the planning meetings.
Another related question is to when and how long the estimation meetings should be done. Here I also have problems to imagine that backlog items for the next several month could be planned, explained and estimated in just an occasional one hour meeting one or two times a week.
Thanks for suggestions and clarifications.
Best regards,
Holger
It is just about viable to run one week sprints in Scrum. I've done it consistently as a Scrum Master for an 8 month period. There are in fact certain benefits in doing so and Jeff Sutherland uses this in his Shock Therapy approach to agile adoption. It is very demanding and the ability to constrain planning, reviews, and retrospectives to an appropriate length is indeed very difficult. However, it is possible and it should not be short-changed. Allow at least half a day. You could reasonably allow an entire day for these ceremonies (20% of your time).
When planning sessions overrun because of the explanation that is required, it is often because there has been inadequate backlog grooming. None of the requirements introduced in sprint planning should be a surprise to the developers.
Enough tasks should be planned to allow the team to start their work and feel comfortable about meeting the Sprint Goal. You don't have to plan every last task out during sprint planning; there must be an expectation of further discovery; it can (and arguably should) be done on a just-in-time basis.
One of the big pros of story point estimation is that it's quick. If we're spending more than 5 minutes discussing a single story it's a red flag that it is not ready from a requirements perspective. When we saw this frequently, we added sprint grooming meetings with the team to help the PO (me) ask the right questions of other stakeholders to clarify the stories.
My view on sprint length is that 1 week is too short, and you then have too much overhead. We do two weeks. I'd like to try three, we haven't yet because we're worried that the horizon is then too long and we'll slack off in week 1-2.
Maybe you're going into too much detail in planning. My experience is that you discover things on the fly (JIT), but we don't do as much planning as I think we should so I can't offer much as to how much is too much. Do things change a lot even with the detailed planning or do things play out as you planned?
I think that is our main problem. The Backlog Items are to much/to detailed, but also not clear and descriptive enough so they need many explanation. 5 Minutes per Item or lower would be great. Our discussions are much longer. And even with 5 minutes per item, we would need to much time because of to much items.
I'm not sure, how to get the right balance. First, to reduce the items they have to include more and have to have a higher abstraction level. On the other side they must be described more, so that no long discussion is needed. And all that must be on a level that the team is able to estimate that (or if you use story counting deciding if its too big/small).
How many years of exercise does one need to reach that goal? Is it even possible without coaching?
Well it should be measured in months not years to find a workable (not perfect) balance.
If you timebox your planning, and you start with the most valuable items, even if you don't get through all planning, you should get through enough to get started. As the team gets used to the amount of time that they have, they should adapt to reduce talking about the less important details.
Sometimes including too much detail in the story can derail understanding of the desired functionality. If the team has decent domain/product knowledge they can fill in a lot of gaps. What we do (because we have to work in a fixed bid world) is have a functional specification document. This can have a lot of details. The stories can be more sparse, each covering a portion of the specification.
It might help to see an example of a story from our team. Each team will do it differently, and I'm sure we could improve a lot, but it's illustrative since we are very low on details (I used to put a lot of details in but I found it just derailed the ability to understand core feature and timely estimates).
As a B2B customer, I can search documents by ranges, so that I can search for documents in groups instead of one at a time.
Acceptance criteria:
- I can search for ranges in the following fields:
-- Document ID?
-- Date
-- Due Date
-- Amount
-- Remaining Amount
I mean, that's really sparse, but it's enough information to give an estimate and start work. The team is in their third sprint, so they already know about what all those data elements represent. During our discussion, some of the questions that came up were - do we need to validate that start date is before the end date? do we need to validate that the lower amount is higher than the higher amount? do we validate that the amount is a number and not text? We'll add those details to the acceptance criteria if they're important as we progress.
It's not static either. Document id has a question mark... do we allow a range search of document id? We decided it would be a like search because a ranged search didn't make sense as it's a text field.
But your team might not be comfortable with such a low level of detail, so YMMV. Our approach requires a lot of collaboration during the sprint.
How are you doing your estimates?
We do planning poker to relative size the stories. It's quick and accurate enough for our purposes. So we haven't even had hourly estimates for the items (until recently where we are now starting to plan the tasks for each story and putting hourly estimates to them).
This example story was 8 points. It's a bit bigger than our typical stories.
Recently, we've added tasks for each story where we do an hourly estimate. We'll try not to have these bigger than 1 days work, but we wouldn't have tasks of 1 or 2 hours if we can avoid it. But we do this quickly as well. For this story, one task was coding (2 days) and one was testing (3 hours).
So we estimate this will take us about 2.5 days effort. If story points/hours from previous teams is similar (it might not be) we'll probably book double that on our timesheets.
I'm a big fan of planning poker with Fibonacci-ish scale - I've found it great. But then, the hourly estimates at our organization were atrocious so we weren't losing anything by changing.
Note that the most recent scrum guide doesn't mention story points at all, but it's a well established part of scrum as far as I can tell - maybe experts here could confirm/deny.