1

Scenario

In some cases, we cannot complete all the task in the 4 hour that scrum specify by a 2-week sprint. This may be caused by a bad previous refinery, uncertain work or just big changes reveal in the scrum review that force the PO to re-investigate and re-doing things in a short period of time.

Question

So what can we do when the timebox of sprint planning is exhausted, Should we start with the well defined stories, wait more hours to start the sprint or just define it while sprint is up and running?

3

The Scrum Guide defines it as a timebox, meaning the outside time is the maximum time to spend. That being said, if you're going to just continue sprint planning without calling it that anyway, you're just hiding the disfunction. I would be inclined to make what seems like the best call in the moment and then reflect as a team about why it occurred.

For example, if it's taking long because the team is new and they are learning about how to run Sprint Planning while they are doing it, then the problem will resolve itself. On the other hand, if you have a bunch of items ready to work, you may decide to just start with what you have.

It's important to keep in mind that the structure given in the Scrum Guide should help alleviate this problem.

Topic One of planning is what can be done in the sprint from the product backlog. This is where the PO sets their preferred direction and the team weighs in on what items seem reasonable. After this topic, you have a proposed Sprint Backlog and Sprint Goal. This can be enough to go on, though it'll be rocky.

Topic Two is for the team to put together a preliminary plan on how to do the work, starting with the backlog items at the top of the list.

Note that Topic One doesn't include planning or tasking out work. It's just selection. This keeps deep dive discussions one one or two items from dragging out and keeping sprint planning from effectively getting done in the timebox. When you move on to Topic Two, you get as far as you get. The first things to be worked on are the first to be talked about, so wherever you get to is fine to start the sprint.

2

Short answer: You start the sprint with what you have at the end of the planning session. During the retrospective, you evaluate why the planning overran the timebox and what can be done to reduce the likelihood that it happens again.

  • Yes and I can do even shorter: "Now the problem is all too transparent, proceed to inspect and adapt." But I'm now really interested in hearing your long answer. Thanks in advance :) – onedaywhen Aug 13 '18 at 13:01
2

The first thing to note is that you don't have to plan everything before you start the sprint. Mike Cohn has a really good post on why teams don't need to think of everything in sprint planning. Don't be afraid to make a start on the sprint and then get the team together every now and then to do additional planning. This allows the team to adapt during the sprint.

Secondly, if sprint planning is uncomfortable that is usually an indication that you are not doing enough product backlog refinement. The Scrum Guide suggests up to 10% of the sprint should be spent refining the backlog.

Finally, this is just the kind of topic that should be raised and discussed during the team's retrospectives. Perhaps the team already knows why this is happening and just needs the time to discuss it and find a solution.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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