Editor’s note: This blog post was originally published in September 2016 and has been completely revamped and updated for accuracy and comprehensiveness.
This article is an excerpt from our new book. For the full guide to building a collaborative software team, pick up your free copy!
Start Sprinting
Once you’ve refined your backlog, set up Milestones, and established a sprint goal, you’re ready to begin a sprint. Congratulations!
After you get started, it all about keeping the project in motion. Here’s what to do during your sprint to keep everything copacetic.
The day-to-day of a development sprint
During a sprint, your Workspace and Boards are at the center of everything you’ll do. Make use of labels and pipelines, and drag and drop issues into the correct places as you move forward.
If you’ve set up a Workspace that reflects how your team actually works, then they should portray exactly where things are at. That’s part of the reason it’s so important that everyone involved with the project uses the board.
It' important to emphasize that a lot of teams aren’t used to this level of individual autonomy. It might feel unnatural at first. Many developers are accustomed to being told what to do, and many managers are used to owning every part of the project management process.
This isn’t the fault of a bad manager or a lazy developer; it’s because most project management workflows and tools are too distracting from the real work (the code) for us to reasonably expect developers get very involved. That’s the reason why we built ZenHub in the first place. If your team isn’t used to this system – or they’re using it ineffectively – gather everyone together and formally introduce them to this new way of working.
With everyone is actively using the Board, your developers will get more done in less time. The project lead will spend less time bugging people for updates. Everybody wins!
Daily standup meetings
Every day, the ZenHub team conducts a short standup in which we quickly state what we did yesterday, and what we’re doing today, along with any blockers or difficulties. Holding it in the morning (usually with a mug of coffee in hand) helps us set the stage for the day ahead. Everybody, including sales, design, and marketing, participates.
Besides being a way to share information and spot blockers, in-person standups are valuable in that they mandate public commitment: you’re proclaiming, quite literally, what you’ll be delivering. It makes everyone accountable over their day, every day.
Watch out for two common mistakes of daily standups. One: we tend to spend too much time talking about our work, and not enough talking about our blockers. Making sure to mention your own blockers is an act of generosity to your teammates.
And two: standups often devolve into technical discussions. They’re meant to be quick, so if you start debating something, take it into a GitHub issue and let the day begin.
Know thyself: Using Burndown Charts
Burndown Charts display your completed work (closed issues) in relation to your projected velocity (how much work you thought you’d get done). Though they’re often associated with Scrum – an agile methodology involving frequent releases, incremental progress, and a focus on customer requirements – they’re a handy little tool for any team.
During your sprint, check in with your burndown charts every day to see if things are progressing as planned. They’re an excellent way to keep an eye on scope. If you find you’ve overestimated how much you can get done, don’t worry – it’s a very common misstep. Simply stop starting new issues and focus on completing (at least) a couple of existing ones.
As an early indicator of how projects are progressing, Burndown Charts can help teams meet deadlines and track their velocity. Since they visually display complete and incomplete work, they’re a user-friendly reporting tool – the quickest answer to the question, “How’s that project going?”
Building out your Burndown Charts
In ZenHub, each Milestone (sprint) gets its own Burndown Chart. To ‘build’ your chart’s x-axis, choose the Milestone’s start and end dates.
When issues with estimates are added to that Milestone, they’ll show up on its Burndown Chart. When an issue is closed or enters your "burn" pipeline, a new data point will appear. You can be confident you’ll achieve your goal if your team’s completed work tracks closely to the diagonal timeline.
Note: You can also customize which pipeline triggers a “burned” task by using the Burn Pipelines dropdown menu:
What’s done is done. Maybe.
When you ask ten different members of your team “when is an issue done?”, you might get ten different answers.
The QA person says it’s done once it’s been tested.
Your developer says it’s done when the Pull Request has been merged to staging.
Your CEO might say it’s done when it’s in the hands of users.
It’s critical to establish a definition of done that everyone on your team understands and agrees on.
Testing and QA during a sprint
If a feature isn’t tested, it cannot be “done”. Thus, testing will be a continuous process during your sprint.
There’s a reason we’re so adamant about breaking tasks into small pieces. The sooner you can complete an issue, the sooner the testing process can start. The closer to the start of your sprint you begin testing, the better chance you’ll have of being able to deliver valuable code by the end.
We suggest adding a “ready for QA” pipeline to keep issues visible and moving forward. Alternatively, use Blocked by: or Ready for testing labels to let other team members know where their help is needed.
Pull Request and code review
Pull requests are GitHub’s way of telling your team that you’re requesting a code merge. Others can review the proposed code, discuss different solutions, and add follow-up changes.
“Code review is essential to readable and maintainable code...
it’s to programming what editing is to writing,” says Trey Hunner, Director of the Python Software Foundation and host of the Weekly Python Chat. “You can review your own code, but getting others involved is often more productive.”
We maintain that having others review your code is a non- negotiable. Pull requests are an opportunity for learning, and we treat them as such. In fact, making pull requests the cornerstone of our developer onboarding allow us to get new team members shipping valuable code Day 1.
To make it work, it’s helpful to have some standardization to what constitutes a “good” PR.
Just like issues, you can set up pull request templates. Here's an example:
(We include a section for customer comms so we remember to loop back with any users who originally requested the feature or submitted the bug.)
So, what else goes into a great pull request?
-
Do create “single responsibility” pull requests which change one thing only. There’s nothing less useful than a “kitchen sink” pull request.
-
Do encourage your team to add a title that describes what will happen when it’s merged.
-
Do make ample use of @-mentions to tag team members on specific parts which may need special attention.
-
And by all means, Do make it a point to also comment on the positives when reviewing another’s PR!
At the end of your sprint, open Pull Requests should be merged, closed, or moved to the next Milestone. By taking the opportunity to make pull requests a hub for constructive dialogue as well as praise, PRs can be a powerful force for mentorship and even camaraderie in your engineering team.