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.
@@JeffBarutt I very much disagree as I have never seen the use of Epics or Features hierarchy in any tool be anything other than a work breakdown structure. - If you have complex dependencies id advise restructuring the teams to eliminate them. - If you need a hierarchy to " enable effective product backlog" then fix that A Product Backlog is a ordered list of work. There is no hierarchy in that definition.
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)?
Really good and clear instructions in a short time. Thanks!
Glad it was helpful!
this demo is GREAT! BUT... the screen zoom is so small! you need to zoom in!
Will endevour to make that easier in the future.
Hi Martin, thanks! This video is really helpful. Still, I wonder why you prefer having tags over Epics and Features. Can you explain again? Thank you!
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!
Oh is there a GitHub repo with the dummy project items, just to have a play around and see how it looks on a local DevOps sandbox?
@@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.
@@JeffBarutt I very much disagree as I have never seen the use of Epics or Features hierarchy in any tool be anything other than a work breakdown structure.
- If you have complex dependencies id advise restructuring the teams to eliminate them.
- If you need a hierarchy to " enable effective product backlog" then fix that
A Product Backlog is a ordered list of work. There is no hierarchy in that definition.
Excellent
Thank you so much 😀
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)?
Not yet, but Ill add it to my backlog.
You need a good tool to use scrum in Your project
@@nakedAgility I am waiting to see that video soon. Thanks much :)