This post is a follow-up on “Bootstrapping A New Project”
“User Story” is an important communication tool, it is used between you (the developer) and who ever is making the requirements (the stakeholder). A “contract” which (unlike one written by a lawyer) is clear, understood and agreed upon. On our side (development) user stories embody a work unit that can be further broken down and estimated.
Key value points:
Hmm.. OK, thats pretty clear, but suppose this can be written clearer, lats try using the following template: (not my invention;))
As a [role], I want [Requirement / Feature], So that [Justigication/ Reason]
The requirements now look like this:
By reading the above I can clearly understand the required functionality and the motivation behind writing it, this gives me a good starting point. Since I am the one to implement this, I will need to provide estimates, so that product can plan ahead and communicate the product road map onward. Unfortunately, “The Devil is In The Details” as they say, so giving estimates based on points 1,2,3 is still difficult. Points 2 & 3 are “huge” stories, also known as “epics”, we need to further break down these stories, while still using the same language and practices:
The functionality expected of deliverables from the points above is clear, and now I feel more comfortable estimating the time it will take me to complete each. Along with the estimation, these can now be prioritized against each other and against other ongoing projects..
The beginning of a new project is the perfect time to introduce user stories, it will help with getting the conversation going, further clarifying the scope and requirements. While the project scope might change, user stories are (optimally) modular, decoupled and encapsulated, this should help with managing changes and their effect on the overall project.