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.
A WIP limit really depends on the team and what you are trying to accomplish. WIP Limits can encourage team work, expose bottlenecks and reduce multitasking.
To encourage team work, drop the WIP limit lower than the number of people on the team. For a team of six developers, a WIP limit of three would mean that every developer was pairing up to work on a story. If you wanted to try out mob programming you’d drop your WIP limit to one. If you want each developer to work one thing as individual then set your WIP limit to the total number of people on the team.
To expose bottlenecks in a specific column, drop your WIP limits on that column. That will force the team to swarm on the problems that are causing the back up.
To limit task switching reduce the WIP limit. If the WIP limit is less than or equal to the number of developers on the team, then developers shouldn’t be working on more than one thing at a time.
Closing the retrospective provides moments for continuous improvement, for reflecting on what happened during the retrospective, and for expressing appreciation.
I’ve recently lead a few retrospectives with teams that are new to a five step retrospective. I wanted to keep the closing activity as quick and painless as possible. I found an activity on plans-for-retrospectives.com called Feedback Door – Smilies. I modfied this a bit for the retrospecitves I led.
Smileys on the Door
Hand out stickies and sharpies to all of the participants.
Draw a smiley face :), meh face 😐 and a frowny face 🙁 on a whiteboard or a stickes so everyone can see.
Explaing that, “This last activity is to close and gather feedback on this retrospective. Take a moment to think about the retrospective as a whole and then draw a smiley that represents how you feel. How did you feel about the activities? How did you feel about the things we decided to do? When you are finished, you can stick your smiley on the door as you leave.”
In a recent retrospective a question came up about morale. That triggered a memory about an activity for tracking the mood of a team. I tried to recreate the activity as best as I on the spot. This is how it went. We passed around sticky notes, everyone drew a smile, meh, or frown face to capture their overall mood from the previous sprint. The papers were folded / crumbled to keep them anonymous. The votes were then tallied and then we discussed the results.
Obviously this method of capturing morale can lead to skewed results. It’s hard to sum up or even remember all of the things that affect your mood during a sprint. If someone is really happy or mad on the day of the retrospective, that might lead to an overall mood that doesn’t take into account the other days of the sprint.
Since I’m a developer my mind naturally jumps to solving this problem with software. So I wrote up a little application to track my team’s happiness. The code is available at github.
The inspiration for this comes from the niko-niko calendar. One major difference is that this project is designed to “anonymously” track moods. Data is captured at a cookie level to link a single users stats over time, but there is nothing that will identify that person beyond what the put in their notes field.