Thoughts & Notes on User Stories
Details about breaking user story added
I have had a love-hate relationship with Agile. The reason has likely been I didn’t realize it’s effectiveness.
These are my thoughts and notes on User Stories. I hope to improve and expand on these ideas in upcoming months.
The goal with user story is to deliver the best value in smallest/most efficient package.
This would void un-neccesary rework, make sure we start the story at the right time and help make estimate for how much work can be done within a fixed time.
The lessons one can gain from creating user stories, splitting, making DOD, making DOR, etc are all transferable skill to personal planning as well.
Writing User Stories
Guiding phrases help narrow focus.
The description can be phrased this way.
As a <user> I want <outcome> so that <business>
<outcome> can be used as story title.
The dichotemy of User Story and a Technical Task
By the symantic of it, user story is about something a end user wants. So user stories map to features that effect users.
While developing there are also other tasks such as database migration, job creation, etc that aren’t user stories. These are technical tasks.
It’s better to classify it separately so that a business user doesn’t get confused by it.
But here is the catch, if you separate them, the business user will prioritize business stories over technical tasks. But aren’t business stories dependent?
Therefore, in real world it’s much better to have only user stories. A user story can be large if it involves too many technical sub-tasks.
A user story needs to have executable spec (BDD). Technical Tasks don’t.
Breaking User Stories
There are two major story breaking ways:
Horizontal can be thought of as breaking a story by type of activies involved like database, user interface, middleware, etc. This isn’t ideal.
Breaking vertically means to break by functionality instead of by activity.
So it could be a functionality is itself a mixture of 2-3 smaller functionalities. We could break it as such.
Definition Of Ready and Breaking Down
Definition of Ready is when it’s right to start a user story. We don’t want to have a lot of context switches because it reduces productivity.
INVEST is a good acronymn to start with to decide how big story should be.
- Independent: Is the story dependent on any other story?
- Small : Is the story atomic or does it contains multiple sub-stories?
The invest remains same as sizing of stories.
The U is for User Interface.
I found there are other things involved here too, like:
- API : if it’s an API, you may want to do API First Development
- Learning : is there any learning involved?
Definition of Done
Defination of done is when we can say the story ended.
The following I believe is must.
- TDD followed
- Product Owner Accepted Story