Last week I attended the Scaled Agile Framework (SAFe) Product owner and Product Manager Training. I’ve already explained a little about how agile works at UCL. As a product owner it’s important that I get a good grounding in the SAFe framework, which the UCL agile approach is based on. There are some differences with how UCL has adopted and tailored the framework, and some differences in terminology too, but the fundamentals are the same.
The 2-day course was held at the UCL School of Management on level 50 of Canada House in Canary Wharf. The views are spectacular and at that height you can even feel vibrations when planes go past! The SAFe course is a little less dramatic, but still incredibly useful and I learnt a lot more about agile fundamentals. There were quite a few takeaways that I’d like to explore more with the Assessment and Feedback product team. One area that I feel we could potentially work on is our story writing ability.
Stepping back a little, SAFe has a set of customer centric features:
- Epic – An epic is ‘significant solution development initiative’. They can be divided into business epics (capture customer needs) or enabler epics (support architectural or infrastructural needs, ensuring that business epics can be delivered effectively.)
- Feature – A Feature is a service that fulfills a stakeholder need. Each Feature includes a name, a benefit hypothesis, and acceptance criteria. A Feature is sized or split, as necessary, to be delivered by an Agile Release Train (ART) (set of agile teams) in a Planning Interval (PI). Features definition can be supported by a variety of Design thinking tools – customer journey maps, personas (UCL have a set of these), whole product thinking. Features may start as a one sentence overview with more details added in refinement meetings and during the PI Planning preparation. Features are laid out as: Feature description > Benefit hypothesis > acceptance criteria.
- Story – A Story is a short description of a small piece of desired functionality. A Story is written from the perspective of the user. Stories are small increments of value that can be developed in days and are relatively easy to estimate. Features fit in one PI for one ART; Stories fit in one Iteration for one team.
This might not make a huge amount of sense to those new to SAFe or agile. To help us out here is a Chat-GPT generated analogy (I asked “Can you given an analogy for how epics, features and stories work together in SAFE agile”).
Imagine building a city:
Epics: These are like envisioning entire city districts. For instance, a “Business District Epic” would involve plans for skyscrapers, transportation hubs, and parks. It sets a broad direction without delving into specifics.
Features: Within the Business District Epic, there are substantial projects, each analogous to Features. One Feature might be “Construct a Central Train Station,” another “Develop a Park with an Amphitheater.” These are more specific projects serving distinct purposes within the district.
Stories: Delving into the “Construct a Central Train Station” Feature, there are smaller tasks, like “Install Benches in Waiting Area” or “Set Up Digital Train Schedule Displays.” These are the actionable tasks to achieve the larger feature.
To summarise:
In SAFe Agile, envisioning a city is akin to developing a product. Districts (Epics) outline the broad vision. Major infrastructure projects within those districts (Features) break down that vision. Specific tasks within these projects (Stories) detail the work to realise those features. This structured approach helps in translating grand visions into actionable items, ensuring systematic progress towards the end goal.
One thing the product team certainly spend a lot of time doing is writing these user stories, or short tasks. There are actually two types of story – ‘User Stories’ express desired end-user functionality written in the user’s language and ‘Enabler Stories’ support exploration, architecture, infrastructure, and compliance.
Within agile there is a very particular way to write user stories.
As a (user role), I want (activity) so that (business value).
- User role is the description of the person doing the action – who is it for?
- Activity is what the user can do with the system – what do they want?
- Business value is why the user wants to do the activity – Why do they want it?
For example if writing a story for ‘Install Benches in Waiting Area’ we might write: As a traveller, I want to have benches in the train station’s waiting area so that I can sit comfortably while waiting for my train.
User stories also have acceptance criteria. In this case the acceptance criteria might be:
- Benches are made of durable, weather-resistant material suitable for heavy public use.
- Benches are placed at intervals allowing for easy pedestrian flow and are spaced sufficiently to maintain social distancing.
- Access for differently-abled individuals is ensured, including sufficient space for wheelchairs and strollers.
Writing stories isn’t always easy. Luckily there are some suggested approaches. One support mechanism taken from The Humanizing Work Guide to Splitting User Stories is to use INVEST:
- Independent – Write Stories that can be developed separately
- Negotiable – Write Stories in which scope can be negotiated
- Valuable – Write Stories that are valuable to the Customer
- Estimable – Write Stories that can be estimated
- Small – Write Stories that can fit into an Iteration
- Testable – Write Stories that are testable
Another support approach suggests using Card, Conversation, Confirmation – to ensure stories have been discussed appropriately. Basically write it on a physical or digital card, have a conversation about the details (between the product owner and the agile team member responsible for the story) and confirm correctness using the acceptance criteria.
There are also suggestions in ways that large stories can be split in to smaller stories also taken from The Humanizing Work Guide to Splitting User Stories. The article starts off by describing a user story as ” a description of a change in system behaviour from the perspective of a user” – which is a helpful way of thinking of it.
- Workflow steps – can you split the story so you do the beginning and end of the flow first and enhance with stories from the middle of the workflow? Can you take a thin slice through the workflow first and enhance it with more stories later?
- Business rule variations – Does the story have a variety of business rules? (e.g. is there a domain term in the story like ‘flexible dates’ that suggests several variations?) Can you split the story so you do a subset of the rules first and enhance with additional rules later?
- Major effort – When you apply the obvious split, is whichever story you do first the most difficult? Could you group the later stories and defer the decision about which story comes first?
- Simple/complex – Does the story have a simple core that provides most of the value and/or learning? Could you split the story to do that simple core first and enhance it with later stories?
- Variations in data – Does the story do the same thing to different kinds of data? Can you split the story to process one kind of data first and enhance with other kinds later?
- Data entry methods – Does the story do the same thing to different kinds of data? Can you split the story to process one kind of data other kinds later?
- Defer system qualities – Does the story get much of its complexity from satisfying non-functional requirements like performance? Could you split the story to just make it work first and then enhance it to satisfy the non-functional requirement?
- Operations – Can you split the operations into separate stories? Does the story include multiple operations? (e.g. is it about “managing” or “configuring” something?
- Use case scenarios – Does the story suit different use cases? Can you split by use case scenarios?
- Break out a spike – Spikes are defined by SAFe as activities such as ‘exploration, architecture, infrastructure, research, design, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate’. If stuck you can write a spike story with the questions holding you back.
While our current user stories are fine, they could be better. We need to remember that the stories need to be user-centric. Ideally the user should be a customer, not a member of the product team – though sometimes the only customer is a member of the product team, for example current API work. Thinking as a user is difficult, but personas could definitely help us here and running through them is a useful exercise – see the ‘so that’ slide below. Thinking as a user also helps us when we think about delivering value and our key performance indicators (KPIs). One anti-pattern we were warned to avoid was providing solutions in the user story.
Once written, using some of the new approaches the training has shared, we also need to ensure that we write clear acceptance criteria. Acceptance criteria provide the details of the story from a testing point of view and are created by the product owner and the team as stories are refined. We were advised to write acceptance criteria using behaviour-driven development (BDD). Behavior is often first described in general terms, which can be ambiguous, specific examples of behavior provide a better understanding. Specific examples can directly become tests or can lead to specific behaviours, which then are transformed into tests. The ‘given, when, then’ syntax is helpful here and can provide a way to test acceptance criteria e.g. Given I am a traveller waiting for my train in the station’s waiting area. When I look for a place to sit. Then I should see benches made of durable, weather-resistant material. We could also look at story maps as a way of ordering and understanding stories.
Lots for us to think about as a product team.
My next task is to read through my notes and complete the Scaled Agile Framework (SAFe) Product owner and Product Manager exam. Wish me luck!
