How are User stories developed?
Well Product Owners (POs) write the Epic and userstory for the team. However, improving the userstory overtime is what I mean by developing a userstory. Userstory development can be challenging journey but one that should be marked by experts and simplicity hopefully.
The initial idea for a feature is not going to be the final product. Stakeholders read and review your user story, and it will change with feedback over time.
User stories are collaborative in nature, it has the many ‘stakeholders problem’. In which every stakeholder interprets truth from a different perspective, so often conflict occurs due to competing priorities. As a product manager, you must listen to many different points of view. You usually have to come to a compromise. If you are lucky you get to design and implement something that all stakeholders will love.
Stakeholders:
- Project Managers want to track deadlines and budget
- Product Managers was to ensure customer needs are met
- Executives want to control or over-contribute
- UI designers want beautiful designs
- UX designers want the design to be usable.
- Software Engineers & Programmers want to implement functionality or the latest technology.
- Customers needs feel and see the user experience that gives relief to their pain.
For the most part you will disappoint many stakeholders, the only stakeholders you don’t want to disappoint are customers. Don’t disappoint customers. In the process of creating a product and software its kin to a rock tumbler. A rock tumbler is device that polish rocks by rotating rocks with sand. Product development is a process filled with conflict, however that conflict is essential developed a polish product.
What is a Userstory? From the book “User Stories Applied for Agile Software Development by Mike Cohn Quote
“User stories start the process by writing down just two pieces of information: each goal to be satisfied by the system and the rough cost of satisfying that goal”.
TDLR: “user stories represent functionality that will be valued by users” by Mike Cohen
Userstories help get to the most valuable parts of features and leave behind vague details. This comes down to game of evaluation & comparison, when you write lot of userstories you will get idea of what is a more important to customers versus what can be delayed for success.
Here I developed a userstory template you can copy to get started.
Why should you use Userstories?
Userstories are way to maintain balance between all stakeholders.
If one stakeholders dominates the conversations the outcome for customers will not be what is expected. For example if executives or middle management dominates the conversation around the product and the software, the functionality that makes most money (trend following) and in shortest amount of time is prioritized without consideration for developers to even realistically deliver that idea in the first place.
A business case study of this behavior can be shown with World of Warcraft & Blizzard’s other products. Once Blizzard and Activision merger occurred there were layoffs and replacement of heads of product development and software engineers thus removing the developers point of view and customer point of view from conversations.
This is great read on the design of world of warcraft due to the lack of player interaction.
Currently management followed fads & trends of Fortnite and microtransactions. We have warzone battle passes, microtransactions around mounts, and wow tokens. A virtual in-game currency to be purchase by USD to buy skins or level ups to skip the “grind”.
However the journey, player interactions, or the grind is what customers want to play, that is why we see the popularity of hardcore World of Warcraft. Where your in-game character dies its permanently dead, you lost all that progress. Which makes the progress of leveling and their journey more meaning full. Right now in 2023 Blizzard’s product line up is experiencing major product drift in World of Warcraft and Diablo 4 and disappointing customers with no PVE in overwatch 2. Customers are frustrated and yearn for past IPs some even going to develop and code their own solutions. Blizzard today realizes this and brought back Chris Metzen as executive creative director. it is yet to been seen if this will pivot the firm back to its former glory.
Now back to user stories the same thing can happen with Developers who dominate the conversation. Developers can push other stakeholders out due to simply having power to implement said solutions. If developers become designers does that speak to years of experience UI/UX designer has? Basically when developers become designers we see complicated ideas and technical jargon replaces the language of the customer and fail to create transactions for the business survive.
You can see this behavior commonly with crypto products or business.
There is a high level of complicated technical jargon. White papers describe this common technical implementation. It is presented as some sort of revolution. You can see the graveyard of 2023 dead crypto business and companies here.
Overall its best to keep a balance between all stakeholders and define business requirements upfront. Inside of companies from small to large, this situation becomes emotionally difficult for all parties. It becomes political very fast if the communication is not facilitated.
User stories essentially are “conversation piece” for your team, its something you make, so all stakeholders can a hold conversations and write down their confirmations. However, how much detail? is too much detail? Mike Cohen recommends that the “development team and the customer to discuss these details.”
What makes a good “acceptance test”? That the code/UX matches the expectations of user/customers. Customer teams write user stories written in language of the business.
How to use userstories
So the customer teams or product owner writes the userstories and then developers estimate the size of each story. Then the product team and developers in a sprint of 1-4 weeks implement that userstory. This short timeframe represents what we call iterations. You will write so many stories we can prioritize and sort user stories per iteration. This iteration on a bi-weekly or 4 week basis is going structure release schedule.
Because coding or writing software is so difficult to estimate the ability to write user stories and move them between iterations or sprints. Allows customer team, product team and developers to execute better because if user story is too complicate it gets pushed or broken down later to be implemented into task.
Why is it? So difficult to build software
Why is it so difficult to write specifications for software? I think it has to do with fact that every industry has different set of logic or system thinking related to software. Specifications can vary in terminology for documentation and in the desire outcome with different workflows. For instance we have many different Specifications:
- Software Requirement Specifications (SRS)
- Product Requirement Document (PRD)
- Functional Specification Document (FSD)
- System Design Document (SDD)
- API Specification Document
- User Stories and Use Cases Document
- Test Specification Document
- Agile Epics and User Stories
- Technical Specification Document
- Data Specification Document
- Non-Functional Requirements Document
- Interface Specification Document
- Deployment Specification Document
- Security Requirements Specification
- Integration Specification Document
- Database Design Document
- Configuration Management Plan
- Software Maintenance Specification
- User Interface Specification Document
- Performance Testing Plan
These specification documents of course are not the same for instance API specifications is not the same as a Userstory. However in small teams, and start-ups, I see the Agile Epics & Userstories are given priority over API specifications. In which teams will prioritize user experience over structure & standardize API specifications, because the outcome customers matter so much more in the short-term to get those early customers. On top of that, the speed at which developers develop why should we nit-pick the API specifications every sprint? its added cost of in terms of time. In an difficult context I think API specifications makes sense for a larger company with many departments and procedures.