A lot of software companies use agile/scrum, and each adapts it to their own ways. We’d like to share today some of the practices we use at GroupBy. Continuous improvement is a huge part of agile/scrum so we would love to hear back from you with your thoughts and best practices!
Scrum recommends 1- 4 weeks for sprint length. At GroupBy, we have found that 1 week sprints work well for all of our teams. We have tried 2 week sprints in the past but have found that too much unplanned works ends up getting added to the sprint. All of our development teams also do sprint planning around the same time (a day after the product owners meeting - in case there are any cross-team dependencies) so the rest of the company easily understands when planning happens and when they can expect to know whether the stories they care about made it into the sprint.
During sprint planning, the teams will go through and vote on any tickets planned for the near future, as well as any additional tickets the product owner may need a rough estimate on (large/important roadmap features, or features customers are watching closely). The product owner shares with the team any context for upcoming tickets, and the developers bring up any concerns such as technical debt or performance issues. A prioritized backlog is created by the product owner with input from the developers, and the top items are added into the sprint based on the team’s capacity.
Daily Standup/Work Invested
During daily standup, instead of going through each person, we go through each ticket that has been updated since the last standup. This is one of the largest deviations from the norm in scrum and we find it works much better for the teams. In fact, I wrote a whole article about how great this is (and you can read it here). We also vote daily on the work invested into each ticket, instead of voting after completion of the ticket for total effort. This helps us remember all the work that was done for the ticket, especially for larger items that span multiple days. This is all done directly in the JIRA active sprint view, as opposed to a physical board. All our client facing teams and even our CEO has access to JIRA, so this just works better for us to communicate to the rest of the company what the teams are working on compared to a physical board, especially with multiple offices.
How does this help us deliver?
There are a few reasons why GroupBy works in 1 week sprints. This cadence allows us to have quick and efficient planning sessions, with the capacity for the entire team to vote on each ticket. Then the developers and the product owner collaboratively put together a sprint based on company priorities, development needs, and capacity, working together to deliver value quickly and efficiently. Tracking our work via JIRA and daily gives us the ability to manage more accurately with each iteration - making us better, faster.