From thousands of hours of customer coaching, we've curated a list of easy-to-implement tips to help guide your planning/review sessions.
The tips below are for teams already practicing Scrum, or Sprint workflows. If you're new to Sprints, retros, or planning, schedule time with a coach here to get more familiar with agile concepts! Or check out the getting started with ZenHub Sprints Guide
Start the meeting by reviewing closed Issues
Take 10 minutes and review what was finished, or closed during the Sprint. Whether it was shipped or closed because it was no longer relevant, a conversation gives the team an understanding of what exactly was worked on versus what you committed to, what was missed, and gives a dedicated time slot to discuss any roadblocks the team encountered during the Sprint.
When reviewing Issues, prompt your team to share lessons learned.
- Did you effectively estimate the Issue? This helps benchmark if you were accurate during Sprint planning
- Anything that came up in the code base, as you developed the feature, etc. that is worthwhile to share?
It's important to not just say what was closed or missed, but to focus on anything unusual that occurred. For example: You estimated work as a 3 and it was completed, but it was actually quite complex; You should share what risks came up mid-flight, and discuss as a team how to surface these going forward for new Issues that might have similar risks.
You can review closed Issues from the board view by filtering by your recent Sprint or from your Burndown chart. In the Burdown chart you will be able to view what Issues were closed during your Sprint as well as any that are still open. Your Burndown chart also provides visibility into any Incomplete Issues within the Sprint. Incomplete means that an Issue was completed out of scope of the Sprint or milestone. So an completed after the end date will be reflected in a separate column which your team can use to analyze during your sprint planning or retrospective meeting.
Board View
Expand the Closed pipeline to review more Issues on the screen without needing to scroll down the pipeline.
Burndown View
Review your scale for story point definitions every few months
Every 3-5 months revisit what each of your story point values means to your team. Ensure everyone clearly understands what a 1, or easy, Issue looks like and why it's 'less complex' versus that of a complex issue in your scale.
Document this in a wiki, or in your repo README. This ensures your scale is fresh, that new team members are onboarded into your way of working, and gives you an opportunity to reflect on what hasn't been working in your estimation workflow.
Use GitHub labels for your research, moonshot project, or experimental Issues
If you're working on a piece of code that's for an experimental project, something that might be 'thrown away', or is going through research (also known as Spikes) to find the best way to move an Issue forward, be sure to label these Issues in the Sprint. Labels are a great way to understand how much time is spent towards this particular type of work in a Sprint.
In fact, we recommend using labels for groupings within Sprints so your team can use the Velocity chart to understand throughput against different Issue types. Learn more
Review open Issues and discuss why completed work is still open
This helps build habits and reminders that people should update work as the update is available (and will help with keeping the Burndown updated in real-time!).
If you consistently find yourself with a lot of open Issues in a Sprint retro meeting, be sure to ask:
- Did something creep up that made this Issue too complex to get completed within the Sprint?
- Is this still a priority against the other Backlog items?
- Is the estimate on this Issue still accurate? Did we identify something mid-Sprint that changed this estimate, which is why it didn't get completed?
More tips on effective Sprints here.
In any planning or retro, discuss out-of-offices for the upcoming Sprint
Reviewing resourcing for the Sprint can help determine if there's going to be a significant change in your throughput. This will help drastically improve the odds you’ll finish the work allocated to your Sprint, as you know to take on less.
Estimate Issues, not pull requests
When reviewing your Sprint and planning your upcoming one, code changes should remain un-estimated.
Instead, always pair PRs with an Issue, connecting the two via Issue <> PR automation. Issues should always have an estimation before being accepted into the Sprint, while the PR should reflect the actual changes to the code to meet the Issue's criteria.
Issues should flow throughout your workflow and be discussed before being worked on, whereas the PR represents the tactical work to make that Issue happen. Using Issues in Sprints instead of PRs keeps conversations focused on the user story/task, not changes that happen after the Issue has already been in progress (code changes).
Do estimation during sprint planning, as a team
If you're adding estimates to Issues individually, rather than as a team, we recommend dedicating time to doing Sprint planning estimation. Here's the structure we recommend:
- Discuss what work is coming up that you'd like to commit to (highest priority Issues in the backlog)
- Pull up each Issue and have the owner or author walk through the requirements and Issue acceptance criteria
- Perform an overview of each Issue together, ensuring you have representatives from all areas of your development team (front end/back end/ops, etc.)
- Have everyone in the room estimate the complexity they believe it will be based on the walkthrough of the Issue
- If there are any large discrepancies in the estimates, (i.e. someone says 1, another says 13) discuss why.
- The process of group estimation surfaces knowledge about your code base, risks, or potential blockers before someone gets assigned an Issue
- Through discussion, you should come to an agreed upon Estimate that then gets assigned to the Issue
- During the Sprint, someone picks up the Issue
Team estimates are stronger because it ensures everyone has a shared understanding of Issue complexity. Estimates that are individually done don’t give insight into a shared understanding of how much the team as a whole can commit to, as everyone’s understanding of a 3 might be different.
Estimating as a team also helps create faster software cycles as you discuss potential challenges before someone begins working on the Issue.