The Scrum Guide sets time-boxes for different sprint events.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint
While having sprint events that are short might be an indicator of an underlying issue, it can also just be a product of a team naturally evolving it’s process to suit them.
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 planning would be spent deciding how much work the team wanted to commit to and sync up with other teams to review dependencies.
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 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 and stakeholders are happy, and the team is continuously improving I wouldn’t worry about how long your events are.
Did you like this post? Signup for my mailing list!
If you have multiple projects and multiple developers you might need to decide if you should dedicate a developer to each project or create teams that can work on all of the projects. While there might be some good reasons to silo work to specific individuals, you should also keep in mind the following benefits of assigning work to a team.
1. More Flexibility
Teams can respond better to unexpected changes in priority / demand. If one project becomes the priority, then the team can shift focus to that.
2. Better Bus Factor
If a only one developer knows about the project, then they become a single point of failure. This is known as the bus factor. Sharing projects with all of the developers on the team can spread knowledge across the team and reduce the likelihood that losing a single developer will bring the project to halt.
3. Higher Quality
When projects are shared across the team, team members can participate in design discussions and code reviews at a deeper level. If independent verification of work is necessary, it’s very easy to share this task across a team. If Bob writes a feature then Anne can functionally test that feature w/ a fresh perspective that Bob might not have. And vice versa if Anne writes a feature, Bob can functionally test it.
4. Improved Morale
It’s great to have the feeling that you aren’t alone in the work you are doing. There are other people to bounce ideas off of who have the same context you do. If the work becomes overwhelming, there are others who will chip in to help. Working on a single project can also become tedious. Having a variety of projects to work on can help reduce burn out and boredom.