We all heard INVEST, and it is a good start to have a good story. Still even knowing about the INVEST we might end up with less than ideal stories. Its always easy to come up with stories that cut on architectural layers, like a story for the UI and a story for the DB. These type of stories offer no real value and they are sure not independent. A good story should go across layers. The key is to have a thin slice across all the layers and show some value. I call it “do just enough”. Do just enough UI, architecture and DB work to meet a story from top to bottom. But the word enough may let you think of sloppy or undone, not true! it needs to be “good” as well and it needs to meet our definition of done. However, it doesn’t need to be perfect. Other future stories can continue to improve the feature based on feedback and good discussion.
The key to a good story is value. We want to express a feature that the customer is going to use. At the essence of the story is a feature or functionality of the software. Creating a table or a stored procedure should not be user stories, but it can definitely be tasks for a user story.
The real hard part is how do you create small enough stories that cut across layers and still do them in one sprint. This sounds like a very hard task. Thankfully the solution is out there and I will point it for you to read.
Breaking up stories is an art, and has patterns like anything in software. You can read about these patterns here:
I have used these patterns and they work like magic. I recommend you learn them and apply them to break stories into small little chunks.
No comments:
Post a Comment