At the heart of every software team is a vibrant culture around creation, organization, and delivery of work. All types of work – be it new features, bugs, spikes… are called ‘issues’ inside of Jira. Issues provide a flexible way to organize and distribute work across the team so that everyone remains productive and the whole organization runs at a smooth cadence. This article will focus on three key mistakes teams make and how to correct them when using issues to track work.
From feature branching to task branching
While using issues to track work in Jira appropriately benefits all teams, software teams have the most to gain from properly sized issues. Typically, software teams use long running feature branches to manage code as merging is a difficult operation.
Git is a new version control system that opens up flexible new ways to work with branches. With Git, branching and merging are easy operations that can (and should) be done frequently. At Atlassian, we advocate a branch per task (issue) workflow. Each issue in Jira becomes a branch in Git. Having each issue on a separate branch makes it easy to move code between branches meaning more flexible releases.
Let’s explore the three pitfalls of teams that sap the power of task branching workflows.
1. Tame giant issues
Product owners often come to development teams with big dreams. Dreaming big is a great thing. We are inspired to stretch ourselves and deliver great experiences. Every big dream requires a set of steps to get there. We need a pathway to get from here to there.
Large epics and features need to be broken down into the major component user stories. Each user story can be broken down into a set of tasks. Each task should require no more than 16 hours of engineering time. Why 16 hours? It’s tough to estimate tasks larger than two or three days worth of work with any accuracy. Also, succinct tasks encourage the team to think about all of the required work to reach the goal.
Common anti-patterns
- Large chunks of work that aren’t well defined inside of a single issue.
- Issues that have summaries like “Build this feature” which don’t crisply communicate the work being done.
- Not tracking work at all!
Strategies for success
When engaging in sprint planning, ensure tasks have a reasonable path and goal. If an issue feels exceptionally big, ask the question of what’s required to complete it. Usually, discussions ensue uncovering hidden work which makes the team’s plan stronger.
2. Streamline your process
Breaking down issues into smaller chunks of work is a good thing. Sometimes, though, the team can go too far. If the unit of work is so small that there are lots of issues to file and manage throughout the lifecycle, issue tracking becomes burdensome.
Common anti-patterns
- Teams that file too many issues find that issue tracking becomes burdensome.
- Engineers voice concerns that it’s hard to know what the next actions are.
- It’s hard to see a path from conception to completion.
Strategies for success
It’s okay to put a few steps of work inside of one issue as long as the issue itself isn’t more than 16 hours (give or take) of work. If your team is using story points, any story that is 20 or more points is a candidate story for being broken down into smaller tasks. Break out the individual steps inside of the issue description so the scope of work is clear.
For more complex work, epic and subtask level issues are useful in making the hierarchy of work clear. For example, one user story may have several required tasks to bring that feature to completion. Using subtasks directly relates each of the individual tasks to the user story. Likewise, epics do the same for user stories.
3. Shut down “ever evolving” issues
What’s the ever evolving issue? Issues should have a clear start point and end point. When issues fester, code flow is compromised. No one likes moving targets. File it, code it, and move on.
The common anti-pattern
Allow me to share a narrative that we’ve all experienced when working with issues:
- Someone reports a bug inside of Jira saying they can’t perform a specific test.
- A development engineer checks in a change that fixes the issue as filed.
- The reporter reviews the fix and sees that while the original issue is fixed, something else pops up in the desired workflow.
- The reporter then reopens the bug reporting that it is not fixed.
Sound familiar? There are a number of dynamics going on that prevent a healthy issue tracking culture. Issues should only represent one piece of work. If the original issue truly is not fixed, then step number 4 is the right action.
Often times, though, the original issue is fixed, but a new impediment arises in the original workflow. In this case, step 4 is the wrong operation. Open a new issue describing the new details rather than polluting the original issue with conflicting data. Link the new issue back to the old issue if you need the reference.
Strategies for success
Encourage those reporting issues to include the desired outcome inside of the issue. That makes it clear to the development team what the reporter is expecting to see when the issue is resolved. Remember, the more detail here, the better.
Kick off a task branch
Task branching workflows depend on a healthy issue management culture. Work is appropriately sized and distributed across the team. Engineers can fully implement work inside of a branch insulating the master from half-baked code. As the user story is under development, continuous integration can run the branch validating that no breaking changes are introduced. Once the issue is complete, the team has an atomic branch to merge into master. This gives the team the ultimate in release flexibility.
Git is at the center of task branching workflows as branching and merging our easy operations. Atlassian has a new solution called Git Essentials that brings together world-class issue tracking, continuous integration, and source control. How do you relate issues to Git branches? We’d love to hear in the comments!