Stories and Epics and Subtasks, ohh my!!
Dorothy the Product Owner
It seems no matter who I ask, I can never get a straight definition of what an “epic is.” I find this fact alarming. Agile teams all over the planet, replete with very intelligent people, opt to organize their work load in terms of concepts with nebulous definitions. That software projects both large and small, public and private, often come in over budget and late should come as no surprise given this fact, and I feel that a certain company, in prime position as the go-to choice for off-the-shelf project management software work and tracking, exacerbate the problem by providing solutions that force end users to classify and structure work into specific configurations, use specific terminology, and enforce hierarchal groupings, because let’s face it, corporations would fall apart without bucketing everything into one class or another. In my own struggles, I just go with a simple definition, epics are a collection of user stories (or tickets, or however you want to refer to your baseline block of work.) The point is, is that, while fixing all the Scrum confusion for every business is beyond the abilities anything or anyone currently possess, it would be nice to chip away at the problem.
But after thinking about the problem, trying to frame the whole scrum-agile work structuring thing into something sensible, simple, and effective is very daunting, so much so that I believe there is ,fundamentally, something wrong with a core tenement of this problem.
I want to propose a change to the paradigm, and I ask you to consider the concept, for you see, this possible solution has been staring software engineers in the face since forever. As currently practice, software work is pushed through a queue, with little stories marching through one end of the pipeline and out the other or sometimes across a board like a game of Frogger. Unfortunately, software engineering is a nontrivial task, and for this scheme to succeed, a great deal of planning must go into sequencing the tasks in the correct order or the sprint will fail, tasks will have to be retracted, contexts have to be switched, and velocity suffers. Teams try to create frilly hierarchies and shoehorn the work into them in the hopes of making better sense of the sequencing and timelines.
None if this is necessary. Instead of spending time in meetings planning this out, let’s start doing the things, starting with the most pressing need of the stakeholders. Instead of reconstructing the need into sequences of blocks of work, simply abandon the notion of a sprint queue and put them into a stack. Yes, that stack. And once that discovery finds the next big bad blocker, that work goes on top of the stack. Now the engineer is working on a new item, and continues to work on the item until it completes or requires a new block of work to go on the stack.This continues until, inevitably, all unknowns are brought into light, the minimum scope has been defined, and suddenly, blocks of work come flying off the stack at a rapid clip, and the deliverable gets shipped. Woohoo!
I recommend trying out this paradigm if not for work related tasks, but thinking about your own big projects and using a stack to break it down and start getting things done instead of trying to map out exactly how you are going to move your mountain.
Top comments (0)