Product Management has a confusing array of different guides, frameworks, jargon and buzzwords, techniques, and tools. OKRs, North Star metrics, JTBD, and dozens of other concepts compete for attention, leaving both aspiring product managers and companies who need them floundering or seeking clarity. There is really only one principle you need to know:
Shorten the path to value.
Gojko Adzic and the good people at SpecFlow published a series of posts on advanced topics in Given-When-Then scenario writing called Given-When-Then With Style: The Community Challenge. And, good news for us practitioners, the “community challenge” part means it's an all-skate! Each week's post describes a specific situation that some find difficult to express in scenarios. Anyone can propose a solution. The following week's post considers some of the proposals, describing drawbacks and benefits of each, and presenting a detailed exposition of a top solution. I highly recommend the series.
This week's Pauses and Timeouts challenge is on handling situations where there is a pause or timeout in the activity. I've dealt with many situations like this, and handled it in various ways in scenarios. In one case, a shopping checkout required payment processing which eventually delegated to external service provides. In another example, an application queued report requests and notified the requestor to retrieve their report once it was ready. More recently, I worked with a system in which data modified in a mobile app was expected to appear for workers in a different role who were using a Web application to manage operations. As Adzic notes in the Pauses and Timeouts challenge, this situation “is symptomatic of working with an asynchronous process, often an external system or an executable outside of your immediate control.”
Here are a couple of approaches I've used.
TL;DR * Frequently maintain and refactor * Split feature files and organize in folders * Don't limit yourself to Connextra user story format in the description * The best description might be no description!
The latest SpecFlow Given-When-Then community challenge (#4 in the series) asks about feature descriptions. The challenge asks three different questions:
By the time I had read to the end I knew I wanted first to explore the generic/vague anti-pattern, define “reports,” discuss finding the right problem to solve, and explore how to link solution ideas to a person's needs. Only after I fully understanding these problems and questions would I be ready to offer thoughts on the challenge’s central theme of descriptions (which is in Part 2 here).