Shipping new product features can be difficult. Shipping new product features that live inside another product comes with its own set of challenges.
As ZenHub matures, we’ve had to get creative to continue making improvements to the product while also enhancing the experience of GitHub itself. So when we decided to bring Board Issue Notifications into a recent sprint, we knew we’d need to quickly grasp the complexity of how we could bring a much-needed feature to GitHub.
By using story points from the planning stage right into deployment, product, design, and engineering had the confidence that they had properly scoped the project’s complexity and understood how any new code might impact our users’ workflows on GitHub.
Before Board Issue Notifications made its way into ZenHub, it existed as a simple feature request within our product backlog. We had personal experience with the frustrations of not being able to see how projects were progressing. After we validated the need further by talking to users, it was easy to decide to prioritize the feature. But before product and design could take the request to engineering, they needed to write out user stories for the feature—a process in which short, simple descriptions are written to provide a clear understanding of what the feature’s goal is from the perspective of the user.
As a rule of thumb, product and design will use this format when writing out each user story format: “As a user I want [x] so that I can [x]”
In the instance of Board Issue Notifications, we were able to determine the following user stories:
1) “As a user I want to be notified on the Board when there is new activity for an Issue I follow so that I can find what an Issue needs.”
2) “As a user I want to learn what the Issue notifications on the Board means and how I can interact with it so that I can take action.”
Without clearly defining these user stories, we might have found ourselves working toward building a feature without an explicit end goal, potentially rendering the feature more of a pain point than a solution to the user’s problem.
Once product and design have shared the user stories with the development team, our engineers can start to estimate. By using story points, they’ll rank the complexity of each Issue using units from the Fibonacci scale—1,2,3,5,8,13,21,40.
While engineering could use T-shirt sizing, this method simply helps to size each Issue—not unpack Issue complexity—which is of special importance to our process here at ZenHub.
To encourage objectivity when ranking, engineers use a rock-paper-scissors method along with hand signals used to represent an estimate based on the Fibonacci sequence. On the count of three, each engineer flashes a hand signal to represent their ranking.
In this instance, as ever, we saw some variance in rankings. After all, these are inherently subjective, and different people bring different experience to the table. For one Issue, one engineer ranked it a 2, while another ranked the same Issue at 5. This allowed both engineers the opportunity to share their experience of working through comparable features. Ultimately, the group concluded it should be ranked at 3.
Once each Issue is estimates, we were able to determine the feature would take two weeks to ship, or one sprint—and we stuck to that. We typically work in a two-week sprint cadence, so disciplines outside of engineering such as marketing and success could prepare any additional pieces of work that needed to be completed ahead of the launch.
Estimations can be difficult to align on, and adding deadlines can be tough to stick to. But without estimations, shipping new features can be even more difficult. Estimates allow us to understand how complex each feature will be before we start implementing, rather than in the midst of a project.