A big struggle, especially with managers, is writing User Stories on internal change and improvement to arrive at the point where we can define clear acceptance criteria, and actually get something DONE-DONE. We managers tend to think more broadly and in abstract terms. Useful and necessary, but certainly not sufficient. One approach that works to get from abstract to “rubber meets the road” is to iterate on the abstract ideas and break down the epic change Stories into smaller, more concrete ones and use the acceptance and INVEST criteria as the litmus test to know if you have something that can be implemented and measured.
An example: “As an R&D manager I want to increase test automation so that I can improve quality and reduce cost.”
As I start to define acceptance criteria, it becomes pretty clear that this story would take “forever” to complete and the acceptance criteria would be so nebulous it would be hard to measure in an objective way. I advocate breaking down these transformation type stories to the point we have something we can implement, and where we can take action today. The breakdown happens using the INVEST criteria.
- Independent – is the Story as independent as possible? Think in terms of organizational dependencies, contention for resources, and competing priorities as a few examples.
- Negotiable – is the Story broad enough to promote some conversation and in my view, some creative thinking?
- Valuable – can we express the story in terms of ROI? If we cannot do it simply, the Story is too big.
- Estimable – can we put a meaningful estimate on the Story? If it is a Story that will take months to complete, it is too big.
- Sized Appropriately – I like to use estimation and acceptance criteria to measure this dimension. In telecom, everything is big-big. We struggle, because of our large-scale context, to make things small-small.
- Testable – my favourite one. Can we test it in a binary pass/fail way? Crafting organizational change User Story acceptance criteria is challenging.
One other point to consider. As a manager, it is tempting to craft User Stories from your own perspective (as in the example above). Think instead about the people in your organization as the customers, and identify the roles who are impacted by Transformation User Stories. As a tester, as a developer, as a quality prime, as a support prime, as an operations prime, etc. This helps us craft User Stories that are more specific and meaningful, and obviously, helps to size them appropriately. Ask yourself, who is the user of an organization? The one big caution is to make sure the Stories all tie cleanly into the vision of better, faster, higher quality delivery of end-customer business value. It helps avoid User Stories that promote local optimization.
Like telecom products, organizations are large, complex systems. Changing and improving organizations is like building a product. Use User Stories and INVEST criteria, and think about the roles (who), to help break down the epic changes into work you can start doing in your next Transformation Sprint.
Here are some references on User Stories and INVEST criteria.