 |
| Photo by Jack B on Unsplash |
Now you ask why, they answered correctly. Yes they did - in a sense, but did they talk about shared understanding? Or did they understand why things were done that way? Not necessarily. I personally don't like articles that tell you how to write good user stories or how implement it as a method. It's something that needs to be understood, and that's why I'm writing this one :)
So the story begins..
Stories are something that have been told us in the childhood and as a mankind they've been along most of our history - on the campfires and after the epic battles. Stories consist of the persons who are doing something for some reason and there's usually some kind of end result in all of this. Stories touch our emotions and we can empathize to the story characters. When someone tells a story, it's main point is understood and it's shared on the next campfire. After few times it has iterated to more finer form, the knight still rescues the princess from the dragon and get's half the kingdom, but he gets shinier armor and the dragon is more fierce every time.What happens here? I'm not a psychologist or don't know anything about human emotions and learning. Actually a rock has more empathy skills than I. There are some other articles that go deeper into this and it seems that our brains have evolved so that they are quite effective with stories. Well, for me It's enough it works - back to the point. When telling a story - no matter what form it is - you are telling a cause and effect in a way the listeners can relate to it. It's very effective. But the main thing you are doing, is you are sharing information in a way it's remembered - you achieve shared understanding of the core things. Main point in user stories isn't the form which is written so that we can create acceptance tests, It's the story itself. The thing you remember and can relate to.
Stories in software development
We've all seen requirements and how these are usually done. Everything starts from customer requirement, which is written down as "how the system should work when you press the button on this page". The documentation itself falls very deep into the details and we kind of loose ourselves in the system, forgetting the core values. As as story, the tower was located in eastern parts of England, would've been built from white stone, had a pointy roof, the princess had blond long hair, knight had a shiny armor and the dragon was black and had huge fangs. After four weeks without releasing anything you're still arguing about the next thing - the dragon's fang shape and length, color of the knight's shield and the princesses name. The story hasn't been even shared yet (released), but you're knee deep in details. Whenever you get to release it, the story probably is missing the "rescue the princess" part but at least the knight is awesome!Characters in our story
Stories in software development CAN tackle these problems in requirements. You'll probably end up doing the right things by just telling a story instead of going too deep in details. When we think of a story, it has characters, like the knight, princess and the dragon. These can be thought of as our user personas, which tells us why they do the things they do, what motivates them to act like they do and what are the core values of them. Previously our knight seemed to be motivated more of the way he looks than the fact that he could live happily ever after with the princess. Mapping user personas through storytelling and research can really open your eyes on <WHO> needs to do <WHAT> to achieve <WHY>. Just remember that there might be more of personas than you alone think there were, an UX-designer and sales person probably have their own questions about user personas. Buyer personas might differ from users and UX-wise the different features of users might affect the product in hand. The point being: Try to get shared understanding of the characters in your story, since the value to your product always comes from the users and value is the only thing you're trying to maximize!I jumped a bit ahead of myself. Our knight had a mission, it was the fact that he'd love to earn half the kingdom and live happily ever after with the hottest princess in Norwich (a city in eastern england). He also would want to look great and have a great looking shield. The value is in the WHAT & WHY -part of the user story. It's the core value we need to extract for our definitions. The hard thing in these is that there are usually a lot of WHY's in the stories. In software development, you should first get the big picture, and then iterate under it. For example now our knight wanted a kick-ass looking shield, but forgot to tell you that it should also block dragon's fiery breath. Ask WHY all the time until you find the root answer, what's the main point in doing things.
You can collect loads of stories and values and organize the development. Assess that whether the shield, living place or saving the princess is the most important and implement it first. Try to tell the story forward in small iterations, always as ready as possible to get feedback from it. If the storyline wasn't correct, we can always iterate. We can continue iterating (release-gather feedback-improve) it until we've proofed that our story was correct! After all, you don't know the value of your story until it's told forward. Sometimes it really doesn't change the story if the princess lived in France, had a brown hair and the knight was actually a peasant. Probably the English market wouldn't like it, but in these cases you should ask yourself - is it really worth telling it if it doesn't bring any value? It will eat up your resources anyway? Fail your stories in early stages, that way you know exactly what you're doing and you keep yourself in the right direction.
'
Comments
Post a Comment