Read on Twitter
This is kind of a scrum/Jira specific thing, but for the current planning cycle, I've switched the the focus to epic-centric (rather than backlog-centric) planning and I am AMAZED at how well it worked.
The core practice for this was that rather than fight to make sure every task level story was a good user story (which is a great ideal, but has a lot of practical problems), we focused on making sure every epic was REALLY well fleshed out, both as story and criteria.
The epics themselves are tracked on a kanban board, and go through the stages
Funnel - Inbox
Analysis - This is worth doing, let's flesh i tout
Ready - This epic is fleshed out, has stories, is ballpark sized
In progress - This epic is now actively being worked on
And so on.
Funnel - Inbox
Analysis - This is worth doing, let's flesh i tout
Ready - This epic is fleshed out, has stories, is ballpark sized
In progress - This epic is now actively being worked on
And so on.
The practical upshot of this is that it *really* crystalizes what the activity of refinement is - it is the act of taking the top epic in the Analysis column, and working on it until it can move to the ready column.
It also aligns our work with what our customer wants. In practice, our epics align with the things the customer wants - they don't particularly care about a lot of backend details, they want to know how well the idea is coming along.
On the flipside, it gives our Devs better focus on the goal, rather than tunnel vision on the tasks.
When we were doing this all out of the story backlog, it had the bad result of making for a lot of contest-less work.
When we were doing this all out of the story backlog, it had the bad result of making for a lot of contest-less work.
Context-less, rather.
You can get something similar by leaning heavily into subtasks, but that has some other complications.
Estimation is still a little fiddly. For one team, they sized the epics independently, then did pointing when we got to planning, but for another, they pointed the stories when they decomposed the epic, and used that for capacity planning. Latter was great, but more work.
It worked for the teams in question because Team 1 was mostly doing work of a type they had seen before, so they could get a ballpark guess pretty easily. Team 2 was developing new stuff, so the breakdown was more useful to them. So, honestly, right answer might be contextual.
Anyway, real payoff came in planning. Because the discussion and prioritization had already been done with the epics, pulling *epics* into the sprint went the way I've always been told pulling stories off the top of the backlog is *supposed* to go.
Now, we are ABSOLUTELY sacrificing some agility by working at this granularity, and I need to make some adjustments for things like bugfixes (but don't I always?), but the reality is I work in a corporate environment where agility is one priority, but it's one of many.
If I were working with teams with differently defined goals (especially if they had really clear focus) rather than ones that cast a wide net, I'd absolutely love to be doing this as the story level, but so far this seems to be lining up with the reality of work around here.
:knocks on all available wood:
