Agile Development Series - Epic Hierarchy Is Needed
Introduction
I have been a proponent of agile methodologies since 2004 when I became exposed to the concepts while working on a United States Army application. My enthusiasm for agile practices led me to develop an open-source Scrum project management tool called
ScrumTime. Over the years, my journey with agile has been rich with experience and continuous learning.
Despite the strides made in agile tooling, a lingering question remains: Why are there so few tools that empower team members to visualize the entire project status as a hierarchical tree of related components, features, epics, or stories? I've often pondered on the need for tools that not only define the "definition of done" at the application design-level but also pinpoint hot-spots of buggy behavior like a heatmap overlaid on the application hierarchical design. In this blog series, I plan to delve into the importance of such a comprehensive project view and explore the landscape of agile tools to determine if this is offered today.
Just Break It Down, Right?
In Agile methodologies, breaking down work is typically done through a collaborative and iterative process. The goal is to create smaller, manageable units of work that can be prioritized, planned, and delivered within a short time frame. Here are some common techniques used to break down work in Agile:
Epics and Features:
- Larger pieces of work that can be broken down into smaller user stories.
- Epics represent a collection of related user stories.
User Stories:
- Express functionality from an end user's perspective.
- Follow the "As a [user], I want [an action] so that [benefit]" format.
- Provide a way to prioritize and organize features.
Story Mapping:
- Visualize the user's journey and identify different layers of functionality.
- Helps in organizing and prioritizing stories based on user flow.
Task Breakdown:
- Break user stories into smaller tasks during Sprint Planning.
- Tasks should be small enough to complete within a day or two.
- Helps in tracking progress on a daily basis.
Definition of Done (DoD):
- Clearly define the criteria that must be met for a user story to be considered complete.
- Breaking down work becomes easier when everyone understands what "done" means.
Time-Boxing:
- Set a fixed time frame (sprint) for planning and completing work.
- Encourages breaking down work into smaller pieces that can be delivered within the time frame.
Continuous Refinement:
- Regularly review and refine the backlog during backlog grooming sessions.
- Adapt the breakdown of work based on feedback, changing priorities, or new information.
Vertical Slicing:
- Break down features in a way that each slice delivers end-to-end functionality.
- Each slice should be a small, complete piece of the overall feature.
Acceptance Criteria:
- Define specific conditions that must be met for a user story to be considered complete.
- Helps in breaking down work into tasks that fulfill the acceptance criteria.
Collaboration:
- Encourage collaboration between team members, including developers, testers, and product owners, to collectively break down and understand the work.
The specific approach for breaking down work may vary between Agile frameworks such as Scrum, Kanban, or others. The key is to keep the work manageable, prioritize effectively, and adapt the process based on feedback and changing requirements.
But, What About the Big Picture?
One of the key strengths of the agile methodology lies in its adaptability, allowing for deviations from the initial plan in response to unforeseen factors that may arise during the project's initiation. However, this flexibility can sometimes result in a lack of clarity regarding the comprehensive view of various project components such as features, epics, stories, and tasks, especially as changes accumulate over time.
Drawing from my past experience as a consultant, I encountered a situation where billing the client became challenging due to substantial deviations in delivered features compared to the original features outlined during the project estimation phase. I'm not advocating a return to the waterfall methodology for conventional application development projects. Still, it's essential to acknowledge that for fixed-bid projects or when working within a predetermined budget, establishing high-level milestones or stage gates is imperative even within agile frameworks. This approach helps ensure a successful project completion that aligns with the customer's expectations.
Within the world of the waterfall methodology, a pivotal component is the Work Breakdown Structure (WBS), a tool that empowers stakeholders to attain a thorough comprehension of the project by outlining interconnected components or tasks in a hierarchical structure. This aids in establishing the "definition-of-done" from the client's perspective, ensuring alignment between the budget and the committed level of effort for project development.
In the waterfall approach, this artifact is meticulously developed before the commencement of any project work. Forbes offers a concrete illustration of a WBS, shedding light on its practical application.
In my experiences with agile projects, I've adapted the WBS concept to offer a preliminary framework for clients, management, and development teams. It's emphasized to all involved parties that this framework is dynamic and subject to change. In fact, I refrain from using the term "WBS," opting instead for "Feature Layout" or "Epic Layout" depending on the client. Certain epics, particularly those addressing overarching concerns like security and logging, may not neatly fit into the hierarchy.
From my perspective, an ideal approach involves presenting a visual representation of the Epic Layout that not only conveys project status but also facilitates navigation to more detail. As an example, I've created a mock-up for a basic Epic Layout for a fictitious Todo application.
In this representation, each box signifies an Epic, Story, or Task within the project management system. Boxes with nested components can be expanded recursively, providing a detailed view. Alternatively, clicking on a box reveals specific details about the associated Epic, Story, or Task.
In the next iteration, I've incorporated the feature of displaying bug counts on each box.
This addition serves as a quick indicator of which part of the application is encountering the most reported bugs. The bug counts are aggregated hierarchically, offering a concise overview. Below is a representation of the same information in a table layout with hierarchical ordering.
Either of these visual layouts are useful for me to convey project development performance in a simple manner to all stakeholders. This is especially true when I add metrics such as story points, work hours, story counts, or task counts.
Conclusion
This article aims to highlight potential opportunities for vendors of agile project management tools. The focus is on presenting an idea that can enhance project status clarity and improve navigation for all stakeholders involved in project management. I have strongly felt the need for this capability over an extended period. In fact, I'm becoming weary of consistently creating a dynamic artifact external to the project management tool to monitor and track this information.
Please let me know if you do similar things in your projects or if I am alone on this. I would thoroughly enjoy hearing how you keep your stakeholders informed.
Ernie Paschall