Introducing: Automated GitHub Sprint Planning

As we checked in with our users over the past year, we began to notice a troubling pattern. While software projects were becoming more important to every organization, the amount of time teams were spending on administrative tasks like updating sprints in project management software was increasing at a far higher rate than the amount of time actually spent writing code.

As we thought of ways to tackle this challenge, we realized automation was the solution. In September, we announced Automated Workflows to streamline the hand-off of work between teams and eliminate the need for status updates. Today, we’re excited to follow that up with another automated experience: ZenHub Sprints – the most hands-off way to do GitHub sprint planning.

Why automate GitHub sprint planning?

For teams following scrum, sprints are a critical tool in aligning around what to work on next. Unfortunately, sprint planning meetings happen to be one of the most despised rituals in agile development. It’s not uncommon for teams to spend multiple hours in a planning meeting, only to come away with a marginally better understanding of what to work on next.

As we reflected on this, we realized ZenHub wasn’t doing much to alleviate this problem. While our integration with GitHub Milestones provided a seamless way for teams to plan and track their GitHub sprints without leaving GitHub, it didn’t address the needless amount of manual overhead for project managers at the start of every new sprint planning cycle.

Further, GitHub Milestones are tied to a single repository, which creates difficulties for teams that have more complex workflows that span multiple repositories. Another major limitation was Issues can only belong to one Milestone at a time. This presented problems for many teams as moving incomplete work also removed the story points from the completed Milestone.

To solve these issues, we created ZenHub Sprints, a purpose-built entity to help teams better plan and track their iterations. ZenHub Sprints delivers three brand new automations to help process owners and their teams save time.

Creating sprint plans without manually closing milestones

One of the biggest frustrations teams expressed with Milestones was having to manually close the existing milestone and create a new one at the beginning of each new cycle. Given that sprints occur on a predictable and repeatable cadence, we saw an opportunity to automate the creation of upcoming sprints on a recurring schedule set by the team.

Leveraging the same calendar view that teams have become accustomed to with Milestones, ZenHub Sprints provides an interactive way to set the start and end date for GitHub sprints. Once the duration of the initial sprint has been set, ZenHub will then automatically create the next two sprints based on the duration and the weekday on which sprints start and end.

While it may seem like a simple feature, this eliminates the need for project managers to manually create and close Milestones. Creating multiple sprints at a time allows teams to plan several sprints ahead which further reduces the amount of time spent in planning meetings.

Reduce sprint planning meetings by automatically adding work to a sprint

One area of the planning process where teams tend to spend the most time is agreeing upon what work actually goes into the next sprint, and rightly so. Given that sprints are fixed in scope, time spent prioritizing work upfront not only helps to align the team around the next set of deliverables but also ensures the team is always tackling the most important issues.

As we spoke with our users, we realized ZenHub could also play a role in helping to streamline this process. By defining a “backlog” pipeline and a velocity, teams can automatically build a Sprint candidate up to a certain number of story points. For example, if the selected pipeline is “Sprint backlog” and velocity is set to “44,” ZenHub will automatically add the highest prioritized Issues from the Sprint backlog pipeline up to 44 story points to the Sprint.

While we know the sprint planning process can never be fully automated, providing a sprint candidate can save teams time from having to manually move Issues into a new sprint. The sprint candidate also serves as a great starting point for a team-wide discussion around what work needs to be accomplished and what Issues need to be added or removed.

Never leave work behind

One of the most common questions we hear from teams around sprint planning is what to do with unfinished work at the end of the sprint.  As a best practice, any unfinished work from the previous sprint should always be carried over into the next sprint, unless the Issues are no longer relevant or we’ve learned something that requires a change in strategy.

Despite this being a common and best practice, it hasn’t been well supported until today. As Issues can only belong in a single GitHub Milestone at a time, moving unfinished work to the next Milestone also removes their story points. In effect, with Milestones, unfinished work was never factored into the calculation of a team’s velocity, resulting in a flawed view of the team’s efficiency and unrealistic expectations of future work.

With ZenHub Sprints, we now provide the option for Issues to live in multiple Sprints at the same time. Teams can also toggle on an option to move unfinished Issues to the next sprint.  When a Sprint completes (passes its end-date), all Issues assigned to the Sprint that have not been closed will automatically be moved to the next Sprint.

What are we automating next?

When we launched Automated Workflows last September, we highlighted several focus areas of our near-term roadmap around automation. For developers, we’ll be unlocking some major productivity gains by allowing for Issues and Pull Requests to be connected using GitHub Keywords. We’ll also be making it easier to visualize work in progress by allowing a Pull Request to be connected to multiple GitHub Issues at the same time.

For teams, we’ll be turning our focus to software estimation. Like sprint planning, estimation and backlog refinement is an essential part of the scrum process, but often a major source of frustration for teams. In particular, we’ll be looking at ways to make the estimation process more asynchronous, and highlighting Issues with the largest discrepancies so that teams can focus their attention and discussions on those.

As always, stay tuned for more!

Not using ZenHub? Sign up today for a free 14-day trial.