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.