Very short Sprint Events

Scrum time-boxes are maximum lengths of time, not mandatory ones. Of course a team can finish early.

As regards Sprint Planning, it is often the case that if product backlog refinement is done conscientiously, then there are so few surprises that planning only takes 30 minutes. Check however that this half-hour is including adequate task planning, and that refinement is not encroaching upon this activity (you say refinement is "quite detailed"). Precocious task planning is untimely and invites waste through rework.

As regards the Sprint Review, it is often the case that if WIP is limited throughout the Sprint and an even burn-down is attained, the Product Owner can see "Done" work on a continuous-flow basis. This de-risking of delivery can mean that again there are no surprises, and the event is expedited.

The best teams I have ever worked with demonstrated similar behaviors. The important thing is not to significantly abbreviate the Retrospective, as it is important to make the most of this formal opportunity for continuous improvement.

Thank you, Ian. That leaves me somewhat relieved... :-)

(And yes, in the former "Sprint Planning 2" the task planning is not very detailed, at least not for the tasks that are still some days ahead. And no, the Retrospective is not abbreviated.)

I am still surprised to see a 30 mins sprint planning meeting for 2 weeks sprint. Can you please put down the activities you guys do as a part of sprint planning.

Regards
Sanjay

Hi Sanjay,

here are the activities of our Sprint Planning:
1. We all look at the Product Backlog
2. The Development Team has the opportunity to ask questions regarding the first Product Backlog Item, the Product Owner has the opportunity to state news that could lead to new estimations or changed priorities. Usually, nothing changed since the last Backlog Grooming and the Development Team knows enough to decide immediately if the item can go into the Sprint. So they think about the available development time within the next Sprint (vacations etc.) and vote thumb up (if the item can go into the Sprint) or thumb down (if not).
3. Activity 2 is repeated until at least one Development Team Member lowers her thumb for an item. Only the "thumb-up-voted" items are shifted to the Sprint Backlog.
4. The whole team decides about a Sprint Goal. Mostly it takes us about 10 minutes to come that far.
5. The Development Team discusses the first 1-2 Sprint Backlog Items and breaks it down to tasks so that the next ca. 2 days are set. The Product Owner can give some input, but usually doesn't (except some small questions or information).
6. The Sprint is started and the meeting ends.

I've worked on a few teams that have had short sprint events (planning, retros, and demos). We had one or two half hour backlog grooming meetings during the sprint which would result in a prioritized sprint backlog. Most of the time spent during planning would be spent deciding how much work the team wanted to commit to and syncing up with other teams that we might have dependencies on.

We also had stakeholders who didn't find any value in seeing demos / sprint reviews. We tried many times to figure out a format that would get them engaged but it just never worked, so we ended up scrapping that ceremony all together.

As for retrospectives. They are important but if the team doesn't want to participate (maybe they are burned out and they just don't want to do it) then there is nothing stopping you from skipping that as well. I have a few different types of retro formats I follow depending on the teams interest / engagement level. The long version usually follows the format laid out in the Agile Retrospectives book and those can go up to two hours. Shorter versions include the lean coffee format or just simply asking the team for a single idea on a sticky that will help to improve something for the team.

So as long as you are delivering value, the team, POs & stakeholders are happy, and the team is continuously improving I wouldn't worry about how long your events are.

Posted By Anke Maerz on 16 Oct 2015 03:42 AM

Usually, nothing changed since the last Backlog Grooming

I think that is critical. What happens if either of these conditions change?

This is an interesting approach. I can see some efficiencies with working straight from the prioritized backlog, but I don't see where the Product Owner is actually making their offer to the team. It seems in your process, the Product Owner is completely deferential to the team and their view of what they are capable of.

Not to say this is bad, it is a good sign that there is a level of respect and acknowledgement between the PO and the team. But the PO should also have the respect and freedom to ask for what they need every sprint, even if it pushes the team. This type of conflict can actually be very healthy, and result in even higher productivity and collaboration.

Hi James,
thank you for your thoughts! Yes, Scrum Team and Stakeholders are satisfied with the value delivery - that's why I couldn't see a disease behind the phenomenon. If you all can't see one, too, then I'll just be happy and appreciate my team in the next retrospective for their efficiency! :-)

Hi Timothy,
you are right, our PO doesn't make an offer to the team. But then, at the moment we don't have critical deadlines or pushing customers (working on that, though, but that's a different topic) - so there hardly is a reason to push the Development Team further than they want to go on their own. And it's a rather small team, they do a lot of pair programming stuff and they are skillfully collaborating, so no one thinks, they are working slow.

Thank you all for your help!
Best regards,
Anke.