I realize that for about 10 years now, I’ve been doing project-oriented work — generally, writing software with working software taking shape over the course of months and even years.
I have developed a theory of “progress tiers” in how this work is optimally managed.
Epics are high-level themes of functionality that manifests in software. For example, “E-mail Notifications”. This is too vague to express a specific user feature, but does express an area of strategic importance to the product. For example, it may be that the product is used primarily via the web, that it lacks engagement from some users, and that all users of the system are also active e-mail users. Therefore, it makes sense that the application would generate some e-mail notifications — but, it’s not yet clear which ones are the right ones, how they should look, how frequently they should arrive, etc.
Understanding the priority of Epics helps the team understand its product roadmap and vision, and the strategic context for the functionality they deliver.
The Epic is then elaborated and spawns a Story. A Story points toward a specific user benefit: “As an author, I receive daily e-mails summarizing my post performance.” More importantly, because the Story defines acceptance criteria, it can be scheduled. Once scheduled, actual work on that Story can begin. Now, we have pointed toward a real user benefit, and we have decided to begin work, but we have not yet elaborated how to get there — what the technical implementation will entail, what infrastructure is needed, edge cases, design, etc.
These are left for Tasks. Each Task represents an increment of progress toward the overall story. For example, “Mock up a wireframe of author summary email” or “Prototype admin interface for email notifications” or “Develop manual testing plan for feature”. Checking these off indicates we are closer to our overall goal of delivering the Story. Checking all of them off indicates the Story is complete. The Tasks help us understand the progress of the Story and the opportunities for delegation and collaboration.
Finally, there is the Step. Steps are nothing more than micro-Tasks that allow the engineer or developer working on the specific Task to break down their work and set themselves up for success. For example, a Task might indicate, “Prototype admin interface”, as above, but the Steps might be loaded with technical details: “Understand the existing Jinja template system for admin interface panels” and “Create a new template that inherits from the base template” and “Create new model fields to hold the email notification preferences”. There is no point in sharing Steps with the rest of the team, perhaps beyond giving a status update for pure technical curiosity. The Steps are just a way for that single person — focused on the goal of completing a Task — to better elaborate and understand their own work, in the face of technical complexity.
In my work, I have used Pivotal Tracker for team collaboration, which models Epics, Stories, and Tasks directly. I leave it to my individual team members to pick their own systems for managing Steps. I use Todoist for this. But I know some of my colleagues use tools as various as Trello, an empty Emacs buffer, and a plain whiteboard. I believe it is a fool’s errand to mandate a team use a shared system for managing Steps.
How do you know if something is a Story or a Task? Well, a Story describes the acceptance criteria for a user benefit. A Task merely describes an action that someone on the team must take to get there. Stories are the goal, Tasks are the plan.
How do I tell an Epic from a Story? An Epic cannot be scheduled. It lacks detail. It only indicates an area of potential importance, progress toward which must be weighed against other Epics.
I believe that understanding these tiers of progress helps a team have a crisper perception of its own forward motion.
I also think it helps keep people out of rabbit holes. The poorest-run teams are those that think it is appropriate to pluck a vague Epic like “Email notifications” off the backlog, assign it to an engineer, and simply say, “Good luck with that.” It’s not that the “Story is poorly specified” — it’s that the progress tier is misunderstood.
It’s impossible to “specify” an “Email notifications” story, because it does not describe a user benefit, only an overall strategic product area. Your poor colleague who receives that assignment will stare at it for a few hours, brainstorm a little, perhaps write an email, and then simply browse Hacker News due to a hard-wired cocktail of boredom and procrastination that is guaranteed to intoxicate the brain in the face of uncertainty.