Super Stories .... Features to the rescue!
Many moons ago i wrote a post about the use of epics. How to visualise them and use them as a starting point for large project decomposition (read it here). The world has moved on a bit since then but still I see people I work with struggling with some of the same issues. How to break big projects down into small, valuable, usable chunks that can be delivered quickly by development teams. In my previous post you can see how the epic user story is a stepping stone to reaching smaller, valuable user stories. These days I seem to be discussing Features a lot more with people.
To begin with I find there is confusion around Epics v Features. Note: The Epic I refer to here is the original Epic user story, before SAFe decided an Epic was a different thing altogether
Epics v Features
To begin with I find there is confusion around Epics v Features. Note: The Epic I refer to here is the original Epic user story, before SAFe decided an Epic was a different thing altogether
- What are they & Whats the difference?
- How are they different to user stories?
- What size are they?
Let start with addressing these questions
What are they & what's the difference?
The way I see it? There isn't a difference. Both should represent a slice of functionality or a capability that is too big to be a user story in it's own right.
- The feature or epic is simply a large user story.
- They should adhere as much as possible to the INVEST principles.
- Features should be independent, negotiable, valuable, testable.
- They probably wont be small and this will lead to issues around estimation.
How are they different to user stories?
When decomposing a large project, we want to get to a backlog of user stories to feed to teams. The first draft user stories we identify will often turn out to be much too big for teams to deliver in sprint. This will lead us to break the user story down into smaller user stories. Thus creating a parent-child relationship. The Feature could be something we initially thought was a user story, but once further refined turned out to be too big.
What size are they?
How long is a piece of string? There is no answer for this. Its a judgement call. I always feel that user stories should be small enough for each developer/ pair to churn through 2 or 3 stories per sprint. Rolling this up, I feel like we should be able to define features that can be delivered by a full team in the course of a sprint. 5 devs/ pairs doing 2-3 stories each = 10-15 user stories, surely we should be able to create a sensible piece of functionality from the accumulation of 10-15 user stories?? I'd like to think so.
Size is the main cause of confusion with regard to features. If its a valuable slice and its small, then its a user story. If its a valuable slice and it's too big then its probably a feature. Once complete, a feature should give us an ability to do something that we didn't have before. This is also true of user stories however we may often need to combine the value of multiple user stories to get a something viable/ marketable.
Size is the main cause of confusion with regard to features. If its a valuable slice and its small, then its a user story. If its a valuable slice and it's too big then its probably a feature. Once complete, a feature should give us an ability to do something that we didn't have before. This is also true of user stories however we may often need to combine the value of multiple user stories to get a something viable/ marketable.
What a feature is not!
A logical grouping of user stories or tasks. The feature is supposed to deliver you a distinct slice of value, not an accumulation of disparate small chunks of value.
Comments
Post a Comment