4

The question opposite to this and this one.

Sometime Scrum events may took much less time than Scrum Guide prescribes. Is it a signal, that we did something wrong?

As usual, there is my thoughts on this topic for some clarification:

  • Daily Scrum. I think this is ok, if that event take less then 15 minutes. It's depend on team size. Smaller team - less time.

  • Sprint Planning. As I said in this question, in the beginning of projects (when Product Backlog is not yet refined well) this event took much more time for our team. But then (especially toward the end of projects) we spend much less time for planning, than Scrum Guide prescribes. Should it be a problem for us?

  • Sprint Review. My team never spent less time for that event, than Scrum Guide prescribe. But if it will happen, what it can signal about?

  • Sprint Retrospective. The same as Sprint Review. We always have what discuss with my team. But if it will happen, what it can signal about?

About Product Backlog refinement. The same as Sprint Planning. It took more than 10 percent of team capacity (I guess. I never calculated it exactly) in the beginning of projects and less in the ending. Is this ok?

Improve this question

3 Answers 3

Reset to default
10

What is important is not really how long these events take, but if you get the desired results from them.

For example, the Daily Scrum could take only five minutes because everyone is just giving a task board update and largely ignoring each other, which would of course be bad. On the other hand, it could take 5 minutes because everyone talks throughout the day anyway and so they just need to align their efforts a bit.

Unless the times are really extreme, it's hard to infer anything from the time that isn't easier to get off some other indicator.

As far as the trend you are seeing in Sprint Planning and Backlog refinement, this is normal to a certain degree. If the difference between the beginning and end is substantial, it may be showing some other difficulties. For example, if you are reforming your teams around each new project (or switching around product owners) they may be going back through Tuckman's stages each time, causing them to be less effective at the beginning of the project. Again, other metrics would uncover these sorts of problems much better than time would.

Improve this answer
2

as long as the outcome does not suffer from shortage of time, it's totally normal to have shorter events. 'timeboxing' means that if the allocated time runs out, you must halt the event and go with partial results, it has nothing to say for finishing earlier.

you should check the results carefully though. if team thinks that there's inherent value in finishing earlier (they might see themselves as being 'more efficient' for example), they may abandon quality or thoroughness in favor of speed. in this case the Scrum Master must lead them back to the correct behavior.

Improve this answer
1

To extend Daniel's point, a timebox is not a prescription for how long an event should last. Rather a timebox is simply a max amount of time an event can take before the Scrum Master coaches the team to keep the event within its timebox. If the goal of the event is met before the timebox, all the better.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.