❓ So many routes, where do they go? How best can I navigate through them?
You maybe wondering when to use a feature. Or an epic or a theme. You maybe wondering how long it is until you've finished work for the day (me too!). But for this venture into far off lands (Oz, I am ripping off Frank L. Baum today, fiends) you can get many answers and form many opinions on what is the “right way” to melt a woman break down work. The truth is, providing you are able to break down (or slice) work and everyone is aligned to, and, using the same language, it doesn’t matter - what matters is it works for your team and if it stops working, you can click your heels together three times and change your environment. 👠👠
For clarity, I will summarise the terms most commonly used in technology development and provide a description. As a general rule of thumb, the bigger your organisation and the bigger the work is, the more levels are used. For example a technology department with 10 developer teams could have work broken down across 4 or more levels of hierarchy, smaller departments do not need the extra complexity so would be at home with 2 or 3 levels.
💭Themes: These represent high-level strategic objectives or focus areas that guide the organization's efforts over extended periods, often spanning multiple years. Themes help in aligning portfolios with business strategy and investment priorities.
💬Epics: Under themes, epics are significant initiatives that require substantial investment and development effort. They are large bodies of work that can span longer periods of time. Epics should be sliced definitively, unlike themes which are much broader.
Epics can be further categorised and/or sliced if they are too big into smaller epics:
🧕Business (or Functional) Epics: Customer-facing initiatives that deliver direct business value.
🧰Enabler (or Non-Functional) Epics: Initiatives that support the delivery of business epics, such as infrastructure developments or architectural improvements.
💡Capabilities: These are higher-level functionalities that could spark work spanning longer periods of time (sometimes the lifespan of a product). Capabilities are decomposed into features:
👀Features: Features are services or functionalities that fulfill a stakeholder need. They are critical components that enable the realisation of capabilities.
💻User Stories: These are short, specific descriptions of functionality from the end user's perspective. User stories are small enough to be completed within a short span of time and are the building blocks for features.
👷Tasks: Tasks break down user stories into actionable steps for the development team. They represent the smallest unit of work and are typically completed within a few hours to a day.
In my team, we typically use Epics, Stories and Tasks but adapt as required to make the work more accessible for the DEVELOPERS. This is important as it brings all this gobbledegook to the why bother? Why do all of this? Essentially, what we want to do is click our heels and bring “it” home. As there is no place like home, we will get there more efficiently if we all know what we are doing, why we are doing it and how we are going to do it.
Breaking work down like this, requires a brain 🧠, a lot of heart 💖 and sometimes a fair bit of courage 🦁. Thank you for joining me on this yellow brick roadmap 🟨🧱, I hope you continue with me. Just mind the flying monkeys 🐒.
