0 comments
Various 
Lately we got a lot of discussions at our company about differences between User Stories and other techniques. While user stories are not ideal for guarding scope of your product it instead is doing something very different. It focuses on value. How? Read on.
So what makes the difference in value and scope? Scope is meant to make it easy to find the border between work within the projects definition and work that’s outside the projects definition. And off course work that’s outside of the project is work you need to discuss with your project sponsor if this needs to be done and what money we want to spend on it. Other techniques like Use Cases make it easy to find in scope and out of scope stuff. User Stories are different. Their fine grained structure doesn’t let you easily spot if something is outside of the scope.
User stories on the other hand promote the focus on value. Every story contains the business value it represents. Use cases don’t focus on value. It doesn’t have a paragraph on the value it will bring to the business. When prioritizing a User Story it is prioritized by using it’s written value on the card. This is more difficult when you are using Use Cases. User Stories are more fine grained, so splitting up the value is also something you need to do on a more fine grained level. This improves the focus on building the most valuable first. After you split it up you prioritize again and only start with the story most valuable. As a product owner you will be constantly challenged to identify the most valuable and decide what is most valuable by defining the story. Not on what you find the most logical order to implement the system.
So when you need to create a system supporting a process you will not build step 1 first, followed by step 2. No. You will split up those processes in small stories so you can build the minimal support in step 1 and step 2 simultaneously. The resulting product is more shippable and therefore more valuable in comparison to a product only containing a complete step 1. After you build the minimal support you can decide to make step 1 and 2 more luxurious. But wait! Maybe the minimal support showed in a demo resulted in a stakeholder telling you that he finds the support enough for now and instead wants you to focus on implementing step 3 of the process. In this process you instead focus on building the right thing then on building it efficiently.
Hopefully this improves the understanding some more of User Stories and the concepts surrounding it. If not, then sorry for wasting your precious time J