How I Define User Stories To Promote Behavior Change
When it comes to valuable initiatives, it’s vital to see observable changes in someone’s work. The goal is to create user stories that encourage behavior changes.
Avoid mapping lower-level activities and, instead, break down activities into high-level steps without specifying technology or solutions. Design experiments around assumptions and turn them into user stories. The short description of a story can often leave a lot of ambiguity about the scope of the change.
If a story doesn’t fit the expected pattern, raise the alarm early and consider re-writing it.
Even planning to check the outcome after delivering a story can lead to better writing. A user story should have the same effect as test-driven development on code. It provides focus and clarity, which leads to better solutions.
Small, releasable accounts limit dependencies’ scope, making coordination among teams simpler.
User stories are independent so they can be implemented in any order. One or two developers should implement each user story in a single iteration. The reasonable range for measurement is small, medium, and large; however, the goal is to have a single unit of work that needs to be done, we want to measure impact not time to completion.
In the software engineering industry, progress is measured in various ways. The only proof of progress is working software, not any burnout chart.
Measuring effort becomes even more complex when dealing with bugs.
Using activity metrics to assess progress can create the wrong incentives for prioritization. Bugs arise when the problem is more profound than expected, and since software requires constant maintenance, it is never truly finished.
While activity metrics can help check team collaboration, they cannot reflect progress.
