Editor’s note: This article is an excerpt from our newly revamped eBook: Project Management for Teams in GitHub. For the full guide to building a high-performing, agile software team, pick up your free copy!
--
Start Sprinting
Once you’ve refined your backlog, set up a sprint, and established a sprint goal, you’re ready to begin sprinting. Congratulations!
After you get started, it is 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, task 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 task board 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’s 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 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 (as closed issues) in relation to your projected velocity (how much work you thought you’d get done during a sprint.) 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?”
Download our free eBook to continue reading and learn about burndown charts, testing, review and more!
