Feature and Epic are states of a Product Backlog Item. We dont need a seperate work item type to indicate Size or intent, we are better with tags as they are way more versatile. Backlog levels usualy encourage dysfunctional behaviours as we tend to end up in a work breakdown structure, which is the oposit of agility. You cant order a hierarchy: nkdagility.com/blog/you-cant-stack-rank-hierarchical-work-items/
Would have been great to see a single PBI broken into 2 in refinement. And it would have been great to see a pbi with tasks on the board. Sounded like you do advocate for that, so love to see a short addendum video that explained that. Maybe also drop a bug in there. The final request in the addendum video would be to see a little Scrum Team of Teams. Martin this is fantastic and super practical way to manage things in Scrum, love it 👍 So much better than SAFE rubbish which I've seen fail again and again in large multi million dollar government projects...Great video, thankyou!
@@nakedAgility I view this as a matter of semantics. Using a structure to organize PBIs does not inhibit agility in and of itself. The behavior of putting that structure on a strict timeline would restrict agility. It also depends on the product type, such as non-software development projects, that benefit from the Epic/Feature structure to enable effective product backlog management. This also helps when you have a product situation with an external factor that leads to long lead times and work with complex dependencies.
I found the video extremely informative and appreciate the effort put into creating it. Thank you. Do you have any additional resources, such as a video or tutorial, that cover how to define team capacity or determine the number of tasks for a single sprint (a sprint can be 1 or 2 weeks long)?
