Move away from Buckets

Is your teams working in scrum using an Agile framework? What that might mean is that you have scheduled a few ceremonies for the team, and you have adopted an agile ticketing system like Jira, but it doesn’t really matter what tool you use… you are likely bucketing your tickets. 

Everyone starts off bucketing or grouping tickets and work while transitioning to scrum, the real question is are you still bucketing your work? Most commonly this will look like an epic that has been open for 2 - 3 years and continues to grow with new work added to that epic. Developers, POs, team members create buckets for bug reports, buckets to track tech debt, buckets to hold ‘like to haves,’ and more. We commonly use epics to create these buckets to group “like work.” 

Those are all good categories of work but they are categories and. Epics should deliver a clear usable feature. The epic should be defined in terms of the problem you want to solve and the feature that solves that problem. The stories created within the epic are there to support the completion of that feature. Once all the stories are closed and completed, the feature should be reviewed and verified that it meets the requirements and needs of the business, usually in a Sprint Demo or the like, and once the feature is accepted by the product team or the client, the epic should be closed. 

This can be a hard pivot for those who have been working in the world of buckets for a while. Though we all generally understand buckets are not ideal, they are still common and simple ways to navigate tools like Jira. Filtering by an epic is made very easy and is the obvious way to filter in many of these tools, but try not to fall into that trap. Always make sure your epic has a clear outcome and can be completed. Just like a story you are accepting into a sprint that needs to be closed at the end of a sprint, Epics should be sized so they close within or by the end of a business horizon (e.g. Quarterly).

For all those Categories you have now, step back and ask yourself, your team, your product group if they are going to make decisions based on one or more of those Categories. If you’re not making decisions on that information, drop it and don’t worry about it. If you are making decisions then use other fields and filters to get there. In Jira these are commonly labels, but you can use a number of fields provided or work with your tool admins to create custom fields. Then build reports and views that show the data in a way that you can make decisions on it. 

Epics as Features or Deliverables is awesome for so many good reasons. Features are scoped deliverable work. They are also easier to talk about as they have a tangible outcome. Using epics this way also supports longer term programs of work where over time the priority of features for the product may change. If features are stand-alone efforts they can be easily re-sequenced based on client need and demand without the need to re-plan or re-size the specific work. Closing Epics and releasing features feels good as a team, shows clear accomplishment, and is a placeholder and reminder to celebrate accomplishments as a team. 

Start moving away from Buckets...