This page provides a summary and recap of the Webinar: Writing Better User Stories in SAFe that took place on the 8th August 2024. It contains a video replay for anyone who missed it plus a transcription of the voice-over for detailed study. We hope you find it useful.
Webinar Synopsis
Exploring the behaviors that need to be encouraged to get better User Stories!
Stories, or User Stories, are a common way to express each backlog item for a single team to complete within one Iteration or Sprint. Lots has been written over the years about how to write good stories; so why are so many stories still bad? In this webinar we describe where the user story concept came from, the true purpose of stories and explain ways that teams can avoid falling into the trap of doing work rather than delivering value. We describe how in SAFe the purpose of stories can be different to other agile development practices, since SAFe describes a Feature as being a releasable item, not an individual story. And we explain strategies to slice a SAFe Feature into stories.
The final in a series of three webinars that look at the primary backlog items within SAFe: Epics, Features and Stories.
In this webinar we’ll be looking at some of the strategies you can follow when writing User Stories to encourage agility as well as improve productivity.
- Epics (see replay)
- Features(see replay)
- User Stories (this webinar)
Webinar Replay
Writing Better User Stories in SAFe held on the 1st August 2024.
Video Transcript
Definitions
Let’s just get started at the very beginning. What are we talking about here, what are these Stories, and what are they not? That’s a useful thing to think about.
So, let’s go back and look at some descriptions or definitions. I don’t know if you’re a follower of Ivar Jacobson International, but we’ve had quite a few webinars recently. One of the webinars in the last few weeks was with Mike Cohn. In that webinar, he shared this definition with me: “a User Story is a short, simple statement telling us something that a user or a customer wants, and it’s often described as a promise for a conversation”. So we’re starting to get a feel about what these things are. It’s short, it’s simple, it’s concise, and it’s focused about what the user wants, not we are what we are going to do.
An alternate one, which is also very useful, is from the actual inventor of Extreme Programming, because the whole concept of Stories or User Stories comes from XP back in the 90s, and so Bill Wake, who was a co-inventor of that, he said “Stories are like a pidgin language”. A pidgin language, as you probably know, is kind of a simplified language that can be used by people who speak a different language to one another, so they can actually communicate with each other. And of course, that’s true, isn’t it? If we’re talking to users who come from a certain world and from customers and business, and we have other people who are talking as software developers or, you know, analysts, they quite literally have a very different lexicon and a different expectation. So here’s a pidgin language where “both sides, users and developers, can agree, enough, to work together effectively”. Bill Wake’s definition is really interesting; he’s showing how this is an important thing, to actually share that communication and understanding between the people who want the stuff and the people who are going to make the stuff. So I find these definitions quite useful.
Writing Stories using templates
Now, as you probably know, you could write your Stories or User Stories in a template. That is the Connextra template, invented by people in a company in London back in 2001. And it goes, “as a user type”, whatever the user type is, “I want to do” this thing “so that” I can achieve this value, this success. Very simple, just a sentence, but it does make sure that we know who it’s for, what they want to do, and why they want to do it. I’ve said you could write the Story using that template and it is somewhat helpful, but I don’t think you need to bend over backwards in order to conform explicitly to the template, but you do need to think about what’s the purpose and what is the information that I would like to capture that’s talking about what it is that the person who wants to use the Story wants, not what I’m actually going to do, necessarily, or any internals.
So if you go back and think about what the Agile manifesto was talking about, they said that they want to prioritise individuals and interactions over processes and tools. So yes, you could use the template, but the most important thing is, as Bill Wake said, it’s a way to bring together the people that want the stuff with the people who are going to make the stuff and get them communicating effectively. And it’s collaboration, so you have to think about when you write a User Story, have you talked to the user? Maybe, maybe not.
The 3 C’s
If you want to think about how can you write a good Story or User Story, and I tend to use the terms interchangeably, then these different pieces of guidance are very useful and you may well have come across these.
Ron Jeffries, back in the day came up with this idea about the three C’s, that is, the Card, Conversation, and Confirmation. And back in those days, they used to encourage people to write their Stories on small pieces of cards. You know, little index cards. And if you’re as old as me, you’ll remember going to the library and every single book would have had one of these. So these were a common sort of piece of paper in a format around. And it’s very small - you can’t get that much on one side of this card, which means that we only want to create a very concise description of what it is that the user wants on there, because this is not the definitive requirement.
What do we want to do? Well, this is a promise for a conversation. That’s what we saw earlier, what Mike Cohn mentioned. So really, this is not the conveyor of all of the information, but the conversation with the user or whoever it is that wants the stuff, for us to get a much richer understanding, and that’s clearly what the Agile manifesto is trying to encourage us to do, individuals and interactions.
Finally, what they often used to write on the other side was, how do we confirm that we finished it? What’s the confirmation? And that might be a set of checklist items, the acceptance criteria. “I have done this Story and delivered the right value if it does X, Y, and Z”, so making sure that each User Story follows these ideas means that you’re following the spirit of what we’re trying to do with User Stories or Stories, and also it means that you are focusing on that conversation and interaction where you can have a much higher bandwidth exchange with the person who’s the expert.
INVEST
The other thing to think about is, you’re going to be doing this work, but it’s not the only User Story or Story that you’re working with. There’s probably going to be several, and they’re probably going to be prioritised against each other. So Bill Wake also came up with this really nice acronym. You want to INVEST in good Stories. i.e. for each Story you write, you want it to be Independent of the other Stories which are going to be in that prioritised list inside that backlog. Which means, if I change the order and put this higher up in the backlog, I don’t have to move other ones to go with it because there’s no dependencies, so that’s a really powerful thing, but it makes you think about how you need to write the User Story. It’s independence within the items which are in the backlog and we don’t necessarily want to have that many items in that backlog, so that’s the other thing to realise in the background here, that clearly it’s hard to write things that are completely independent of absolutely everything else, but in terms of at the time box of what we’re working on, this might be a realisable thing.
The second thing he says is N for Negotiable, so you should be able to negotiate it. It was a promise for a conversation where we agree, the user and myself, what I’m actually going to do. They’ve got some ideas. They know what they need. I know what can be done. So again, it’s not a fixed requirement or specification that must be followed, we’re going to make that agreement and we’re looking for that negotiation to take place here.
It must be Valuable. It must be something that the user wants, or more generally, the customer wants. Otherwise, why would you bother spending time doing it?
And E, you should be able to Estimate it. It should be estimable. We want to understand the scope of the work and we want to make sure that the investment that we put in is worth the return on the investment, the value which was described in Invest, which means we need to be able to say how long it will take, and if you can’t estimate something, then clearly the scope is not clear and we don’t really understand it, so that’s a good test of that understandability as well as starting to let us think about the return on investment of doing this work.
Finally, we’re getting closer to “Story should be Small” and we’re going to talk about later. Certainly the ones that you’re going to end up doing as a Story, they have to fit within your iteration. That’s what XP said back in the 90s, although their iterations were, I think, a month in their times. That’s going be true when we talk about SAFe as we move on to that as well. Of course, Stories which are not going to be done for a long time, they don’t need to be small and I wouldn’t waste my time making them small enough in case I never end up doing them, so that’s why it also says “sized appropriately”, so if they’re at the bottom of the backlog, don’t waste your time making them small, but if they’re at the top then they must be.
Finally, we need to be able to test that we have actually delivered it and so it should be Testable, and that goes back to the confirmation of the card conversation, confirmation-side. I need to be able to demonstrate that I’ve actually done everything I said I would do – the acceptance criteria have been proved
So, these are very simple, but they’re very useful and they were invented in the 90s or the early 2000s and I still think they’re very good guidance to help you understand if your Stories are good or if they could be improved, if you’re looking for sort of coaching opportunities.
I think the key takeaway is, irrespective of how you write them, if you follow the “I want… so that…” or if you write them in a slightly different way, you have to be really clear about who wants this thing and what value it’s going to deliver to them, it’s talking about what value we are going to give. I’ve used the term “customer” at the at the top of the above image instead of “user” because as you probably know, it’s a bit more complex than just making the user happy, because yes, I absolutely want to make the user happy, but of course the customer may not be the user, so they must also want to buy the thing that I’m making and my company probably wants to make sure that it wants to make me spend the time to build it, and so the builders have to have a perspective, so we’ll probably be thinking much more about a wider stakeholder group.
Who is the customer?
In any case, we need to know who wants this and it to be confirmed that each of the Stories is valuable. And that is the day job of the product owner, to make sure that we’re only doing things that they are happy are valuable and they know who the value is for. I’ve written a list of importance above in blue, which may be defensible, maybe not, but the point I’m trying to make here is that the best User Stories are probably actually going to do something that the user or customer of the solution themselves could understand. But if you can’t do that, then maybe look internally and try to satisfy your business owners or stakeholders in the SAFe world because they’re still some other aspect of your customer or stakeholder. If you can’t do that, then look to writing Stories that are supporting your direct customers as a development team, which are other teams or other trains, maybe helping put stuff together end-to-end much more quickly than it otherwise would be able to do And then right at the bottom of the list, you know, you might choose to do things for yourself as a team, but only if the product owner is really convinced that that is actually useful for the team. This is just a heuristic, but I’m trying to really make the point that you should be reaching out as much as possible to give as extensive value as you can.
What do effective stories do?
Somebody else who’s written a lot about Stories whose ideas I’ll introduce later on is Jeff Patton. He makes this really nice point: “effective Stories connect everyone to the purpose of the product”. So it’s not just the work token telling us what to do as developers; it’s really meant to make us think outside and to think “what is it that we’re meant to be serving in terms of our customers or our users?”. And so we have an understanding and a mental model about what that product is, so we can make that product amazing.
What are user stories not?
Which leads to the question about if that’s what User Stories are, then what are User Stories not? Here are just some thoughts that I had:
User Stories are not requirements in the traditional sense of “it should do this, it should do that”. They are transient descriptions of activities that we’re going to do that will deliver some benefit to the user, but we’re not going to store them away as a permanent record to say “what are the requirements of this solution that we’re building”, and in fact, if you try to do that with your User Stories, you’ll probably just go mad; they are not designed to do that, they are of no use to do that. Don’t spend your time trying to treat your User Stories like requirements.
The other thing that they’re not you can see that User Stories are meant to say “what is it that the user wants the system or the solution to do?”, and so they’re not design instructions, i.e. “make this change to this component to do this”. The assumption is that you will work that out yourself, and that’s your separate activity. It’s not carried inside the information, inside the User Story itself, so those are some of the things that User Stories are not.
And finally, this is what Jeff Patton says, “Stories aren’t a different way to write requirements. They’re a different way to work”. That’s the profound thing that we’re trying to do in any agile way of working, and that’s why Stories have been taken up as such a powerful way of working in any of the agile methodologies. For instance, Scrum just talks about backlog items and yet, of course, most people tend to talk about Stories specifically rather than just talk about backlog items.
That takes me through the first part. Hopefully this is starting to get your mind racing and thinking about things. What’s the Story so far? If I’ve introduced what User Stories are or what Stories are, that was just a very generic description, but this series of webinars is specifically about SAFe, so how do Stories fit into the world of SAFe, and how important are they? So let’s talk about that.
How long should stories take?
To go into this, I’ve used some of the pictures that Brian Tucker used when he was doing some of the earlier webinars, just to have some consistency. Brian was showing this description about the relationship of SAFe Epics to SAFe Features and SAFe Stories. You can see here, if you have an Epic in SAFe, then it will be implemented by breaking it down into one or more Features, probably several Features, and if I have a Feature, it will be broken down into one or more probably several Stories, and so we can see that there is this hierarchy there. It’s worth just thinking about, “how big are these things?”. If you look at the Epics, just to remind ourselves what he said in the webinar, Epics are big, so they’re probably bigger than a SAFe planning interval, because if they were smaller, you would have just called it a SAFe Feature. How many people does it span in terms of doing the work? An Epic could have all of its Features going to a single Agile Release Train in a special situation, but also those Features could just go off in all different directions into many Agile Release Trains in many of your Development Value Streams, so it could stretch, the Features could go all over the portfolio, so it really takes a long time, and it’s got a lot of people working on it in one or more trains. That sounds expensive and hence that’s why there’s a business case associated with that.
Let’s look at Features now. Features are time limited, so they’re designed so that they can be completed by one Agile Release Train in a single PI or less, and in all of these cases we would like them to be significantly smaller than the size of a Pi. If you remember, in SAFe, a planning interval is somewhere around 8, 10, or 12 weeks. Often people will have 12 weeks (quarterly) or 10 weeks, and so we’re saying the Feature must be completable by an Agile Release Train in less than that time so that we get a number of completed Features out of the train by the end of the PI. Notice it’s by the train as well - a Feature only goes to a single train, but we’re not saying whether it is completed by a single team or by all of the teams in the train, or some of the teams, it’s just up to how the train decides to actually do the implementation – but from the perspective of SAFe, a Feature is matched to a train and that’s why we have a backlog or Features for a train, the ART backlog and similarly if we go back up again you’ve got a backlog of Epics and it’s for the portfolio because they could span across the whole portfolio.
Finally, if we head down to what our topic is today, Stories, they are small, they have to be completed within an iteration and SAFe suggests 2 weeks as a standard-sized iteration. Stories are only really for a single team, and therefore there will be a single team backlog, so these really are quite small. Would a single Story be “just” fitting inside a single iteration? No, as a team, you probably want to do a number of Stories in a single iteration.
I was looking at a book from Alastair Cockburn recently and he said, nothing to do with SAFe, of course, but he was saying that five or more Stories coming out of a team every iteration or every sprint seems like a good number, heuristically. These things are small, when we’re talking about Stories.
Why do we split Features into Stories?
If we know that SAFe Features are split into Stories, why do we do it? The reason that we break them down into small pieces is because if you look at the lean thinking, small batches of work will flow through a team more quickly with more predictability than a large batch of work. So it’s just a trick that we’re using. In fact, we’re using it all of the way down. We probably as a company just want to do the Epics most of the time, but the way that we operate is we break Epics into small Features and we break each small Feature into a smaller Story, and this really is the trick to make it flow through the teams and trains and the organisation and hence allow us to be more productive and less stressed as we do the work, even though it might be the Epics that we truly want.
Also, we make the Story small enough so we can say at the end of a fixed time box, the iteration, that this is done, or it’s not done – you don’t want to have a whole load of work which is all half done, because we don’t really know how it’s all going. We’re forcing this artificial time box constraint to say “let’s make these Stories small enough so that they are finished within a single iteration by a single team”.
Perhaps even more importantly, why do they have to be finished in a single iteration? Well, it’s because we would like to get some feedback. We would like to be able to show that stuff to the user or somebody else and see if we’re on the right track. “Is that the right thing? Should we change anything when we go into the next iteration?”. We want to get a small and fast feedback cycle by having small items of work.
User Stories in SAFe
If we talk about SAFe specifically, there is something that you need to know, because you can look at the picture and say that everything has to come from an Epic, but that’s not true. You can have a User Story or a Story which is an orphan. The team decides that they’re going to write the Story, and if it’s prioritised by the product owner and the backlog, absolutely fine. If you think about it, that’s essential, isn’t it? Because we need autonomy inside the agile teams; that’s meant to be an important part of working in an agile way, so they have to be able to put work into their own backlog without it being approved by somebody else.
In SAFe, we would like aligned autonomy because we know we’ve got big strategic things to do, the Features and the Epics, but we still would like to have that wiggle room for the teams to actually do some of their own things. So yes, you should be able to have an orphaned Story.
Calling them User Stories and saying that it’s always for a user, when you’re working on very big and complex solutions, that starts to become a little bit more difficult and so, just like in other ways of thinking about providing value to customers, for instance, use cases where you can have actors which are primary actors or supporting actors, which could be other systems or other things outside of the system, we could do that here as well. So, the behaviour that we’re writing and delivering for a Story could be for a user or a human, but it could also be for another part of the solution in order to make things work, which is why perhaps, calling them Stories is perhaps a little bit more precise than calling them User Stories.
In SAFe, they’ve got these two types of Stories, two types of Features, two types of Epics. There’s the business ones that provide value to people outside, i.e. the users, the customers, and they’re often drawn blue in the iconography of SAFe. And then you can also have enablers, and SAFe describe enablers as being architectural changes, refactoring and those sort of things. They could be things to actually improve the infrastructure, the tools, the scripts and the CDP pipeline. Again, that’s stuff that the customers and the users don’t explicitly care about, but you certainly do as an organisation. They could be experiments and exploration just to generate some knowledge or make decisions; in XP they talk about spikes, Story spikes and so that’s exactly what this is speaking about here. SAFe also says that enablers could be for compliance, regulatory-related things or “you’ve got to finish that document” or something similar. So we can allow Stories in SAFe to also serve those purposes.
Finally, the concept of SAFe is very much that it’s the train that owns the solution and it’s the Features that get released to the customer or customers. The Features are the releasable points and they get released individually or clubbed together into releases, i.e. the individual Stories are not released independently to the customer, although of course the changes are going to the customer as part of a Feature, but they’re not releasable independently from the concept of SAFe because it’s the Features that are.
Why should we care about user stories?
So that sort of raises the question, doesn’t it? If you can’t release a single User Story to the customer, then why should we care about Stories? Should we just do a whole load of work items and just focus on the Features? It’s a tempting way to think about it, but I think that would be a terrible mistake.
And this is why, if you think about the Features that we actually have already, I said that Features must be finished within a single PI. But that means they’re going to take weeks, or even a few months to complete in some situations. That’s a long time to wait if you’re a customer or a user or if you’re an internal stakeholder trying to work out “is this going to be good stuff?”. People will be shouting and screaming “Where’s my stuff?!”. They don’t want to wait. This is a reason to start thinking about: what can we get, incrementally, as we’re building up the Feature as we work on individual Stories.
Lifecycles
Now, if you watched the previous webinar, you would have seen Brian Tucker talking about Features. During this webinar, he said “now that we’ve seen what Features are, potentially releasable pieces of customer value, let’s take a quick look at the journey they go on to become releasable pieces of end user value…”
The point with this is to reframe it with how we were describing Features in the last webinar. Features have a long life cycle. Somebody requests them, we prepare them, and then they’re ready, then we commit to them in PI planning and then they’re finished and get accepted at the system demo by the product manager, but there could be weeks or even months in between that period of time. And of course, afterwards they go off to be released and they live happily ever after.
So notice with the life cycle of a Feature, certainly as we describe it is that there is an extra state: intermediate, where we could say: “maybe we need to preview these things and show our increments and try and get some feedback”. If you wait until you’ve finished the Feature and it’s not right, that’s pretty catastrophic. So yes, of course we want to get the Feature released and accepted, but let’s think about its preview state as well.
Let’s have a look at some of the titles on this card. It might be useful to show an early version of the Feature before it’s finished, just to get key decisions verified, or maybe to get rid of some unwanted Stories, because maybe we decide we don’t need as much functionality as we originally thought. Or maybe just get the product manager excited about the thing and really understand that it’s going to be a really useful Feature, or maybe to show that risks are under control, either technical risks or business risks, or maybe show that we can actually build it, which is how I interpret the viability to be confirmed.
Let’s have a think about this. If I wanted to do these things, clearly I have to do something with the Stories rather than the Feature, because it’s the Stories that I’m working on on a day-to-day basis, and let’s just choose some of these things. How can I get some key decisions verified? I could do a spike, and enable a Story that does some analysis and then allows us to make a decision. Or in some other situations I could do some sort of simple demo and then get people to agree based on what they see. If I pick out some other things, how do we get project managers excited and enthused? Well, it’s not easy, but probably showing them the stuff – let’s show a demo of, not the whole thing, but just some bits and pieces working to really show them the possibilities. And this is before the Feature’s finished. Let’s choose some other things. How can we show that the risks are under control? Well, hopefully by actually making something. Maybe it’s technically complex, so we want to show that our solution actually works, and maybe the architects will be very satisfied by seeing a demo of that, with all the moving parts operating.
These are not the only ways to prove these things, by the way, but I’m just pointing out that some of them could be done with actual demos. If we want to see if the benefit hypothesis is going to be proven, then again that might be a demo where we get real feedback from the customers and from the users. Also, can we build it? There’s this concept of walking skeleton. i.e. Let’s build the minimum viable product just to show that we can make it all work end-to-end inside our software solution, to give us confidence that all the moving parts are actually going to work and that this whole thing is going to be successful, so again, a demo to architects or to the teams involved might be a really useful early thing to do, even though these are internal things in many cases. So we can see that, in order to do an earlier preview as we’ve called it here, we might want to do a single Story, but also, can we always do these things just with one single Story? Sometimes, but often probably not. Can you create a preview of a single Story? Well, it would be best if you can, because it’s great to do as much as possible with as little as possible, so aim to do that, but if you need to do a number of Stories, then we could have to start thinking about which Stories are we going to do in order to do these demos or these incremental internal releases.
Story Mapping
Which brings us to the final topic of this presentation, Story Mapping. If we need to think about how the Stories relate to each other for a Feature, maybe we need to have some sort of visualisation that helps us think and collaborate about these things. The work of Story Mapping is very much based on Jeff Patton’s work, User Story Mapping, which has been around for a good while now. I’ve done some work with him in the last few months, and we’ve actually created some Story Mapping cards and you can download those from our company website. Talking to Jeff, he says that if he wrote the book again or if he revised it, you might well call it Story Mapping: you might drop the User off the Story Mapping side.
Let’s see what Story Mapping is all about, and let’s see how it could fit with us in a SAFe context. The starting point is: we want to work on a Feature, and we might have one or more teams who are going to actually work together in order to deliver that Feature. Just like Stories, we want to think: what benefit is that Feature going to deliver to our users and the customers. One way to think about that quite often is: what’s the journey that the user is going to go through in order to use this Feature in order to allow them to do the thing that it is that they want to do? I’ve drawn the timeline above, going from left to right, and we could start by really thinking and talking to the user and other stakeholders, asking them “what are the key activities or the key steps that you go through?” and we could capture those. The user first does step one and then they do step two, and then they do this thing which we call step three and then they do step four and we would put the real names of those. This is what Jeff Patton would call the “backbone” of this Story Map, and imagine that this is actually on a whiteboard, or it’s on a virtual whiteboard and we’re all looking at it and standing around it and working on it together so we can collaborate. Once we’ve agreed the high level scope of what it is meant to do and, remember, we’re looking at it from the perspective of what the customer actually wants, this is the benefit hypothesis, effectively described in steps and that’s a part of the elements of the SAFe Feature.
Now, we can get our group of people together, which might be a mixture of users, product manager and the team or teams, and we can start brainstorming: “let’s talk about step one, this first activity. What User Stories should we actually come up with, which would allow us to really provide that overall functionality and behaviour to the customer?”. We could do some brainstorming, they come up a whole bunch of ideas and then we could move and talk about step two and then come up with another bunch of ideas, another set of Stories, then step three and then step four. So we’ve got this quite big cloud of Stories here, but notice that they are organised and arranged and they’re related to the workflow steps, so we know the higher level benefit that they’re providing is, and we should therefore be able to see how each of the Stories contributes to be a part of that larger whole.
Scaled Agile do talk about Story Mapping, I think there’s one slide in some of the training courses and what they say is: then you could agree to draw a line to say “what is the minimum functionality?” and moving the Stories that you want to be in scope for a minimum marketable Feature above the line, and moving the Stories below the line, which are nice to have, but we probably won’t do them this time, we might defer those for the future.
Now, that’s a simple solution, and that’s useful, so if that works for you, fine, but we could think about it in a different way, because remember that preview card said that there are probably many things that we want to do, there’s probably many incremental little slices of activity that we would like to work on, so let’s think about how else we could do this.
Instead, we could have a conversation with the whole group saying: “what’s the minimum that we should do to create that walking skeleton, to show that it is actually going to work?”. Because we don’t really know in terms of the technicality. And here the team has said, the Story underneath step one and a few other Stories are necessary. They’re saying that Step 2 is nice, but we don’t really need that, it doesn’t really prove anything from the technical front, so we don’t really care about that, and so that could be our first walking skeleton, that’s an example of one preview that we could do.
Who’s going to look at that? It’s the architects and the teams, in order to feel confident that we can make this stuff. The sooner we can do that, the better, so the fewer Stories in there, the better as well. Then we could actually start thinking about something else and start thinking about the next thing that we would like to do, where we could actually start showing something more substantial, put more flesh on the bones, which the user could then also use and start getting some extra ideas about, and for whatever reason, maybe it’s these extra pieces of behaviour that I’ve actually outlined inside red are for the second increment, if we called it for our preview, and maybe the purpose is just to make the product manager happy if he’s not looking very enthusiastic – they often don’t! And maybe it’s just to get him a bit excited to say “Yep, this is real work, this is a real goer”.
We could keep on going and look at other incremental releases, maybe there is some specific logic to add for that step two, but it we could do it a little bit later because we’re very confident about.
So you can see that I’m actually saying that we could slice things up and have multiple releases for learning, or to prove things, or to get tangible feedback during working on a single Feature. You might also, when you get that feedback from a customer or from the users, actually decide that, all of the things that we thought we could do, they said “I want it early. I don’t really want the extra stuff, so we’ve identified a number of Stories that actually we just don’t need to do”. You’re lucky if you ever get into that situation, but that’s a nice thing to be able to do, so you’re not gold plating your Features all of the time.
I hope you can see that using this kind of concept, which is very simple with a very simple structure, allows you to start thinking about how you could work incrementally, and what is going to be the scope of each of those previews as we’ve described them, or demos that you could do before the whole Feature is finished.
Finally I want to say, the point about SAFe Features is that, they’re not necessarily going to be done by a single team, so don’t write your Features to keep teams busy, that’s a really dumb thing to do. Write Features that deliver value to the customer and let the train work out which teams are going to work on it. So having a Story Map, if you have multiple teams working on it, allows them not only to see what sequence we’re going to do and what scope the overall thing is, but maybe it’s also a case of which team’s going to do what, and we can start talking about the sequencing of the work so that we can actually work at the same time, so my team B, they’re really good at that functionality, which might be whatever step two is, maybe it’s a complicated subsystem team and there’s some complex stuff in there that they can do, whereas the other team, team A, they’ll do everything else and they’re using the Story map to work out how they can all collaborate together.
Conclusions
So let’s just wind up with some conclusions. First of all, from the SAFe Perspective, User Stories are not released independently on their own, but they get released as part of the Feature, but that doesn’t mean that they are not important.
I hope you’ve seen that you should always be thinking about how valuable every single Story is, a) because it’s your time that you’re spending on it if you’re a developer, and you’re expensive, but b) it’s the way for us to focus, to get the most value to the customers and the users as quickly as possible. Don’t just chunk it on a Feature. Make every Story count, hopefully to the users, but it could be for other stakeholders or other parts of the train.
Collaborate and agree which Story or which set of Stories are required to learn, and that was when we were talking about spikes or doing our walking skeleton. Or getting concrete feedback; it’s easier to give concrete feedback of something real if you’re a user or a customer than if somebody says “here’s the spec, tell us if that’s what you want”. We can actually see if we’re going to be successful and so we can reduce the risks, either technical or delivery or business risks, sometimes, by doing intermediate deliveries, and the sooner we can do earlier end-to-end integration between teams in a train or even across different trains if you’ve got a large solution, the better things actually are, if we can actually think and manage those dependencies, so that’s going to be important.
Don’t treat your Stories as requirements and try to treat them as if they’re your permanent record, they just don’t do that, and it won’t work for you.
Don’t write Stories for an individua, i.e. “this is for Bob to do some development code, and here’s another one for somebody to do some testing” – that’s not valuable to anybody else except for that individual, so it’s not a work task. The Story should describe value and it should be done completely by one or a few people inside the team, including the development and the testing and whatever else is required.
If you want to work on lots of Stories, consider using those Story maps in the way that I described and showed you earlier. And especially, because I don’t think SAFe is very good at this, if you have multiple teams working together on a single Feature, you want a way, and a mechanism, and a visual tool to help them work out how they’re going to work together. Sitting in your own corners in PI planning doesn’t really work, and there’s no tangible description in SAFe about how to bring them together, so a Story Map is a good solution for that.
Make User Stories Great Again
Finally, my takeaway is Make User Stories Great Again. The whole point is that they are valuable, they are small, but they’re important because we can get these early demos, we can learn things much more quickly, we get faster feedback. Don’t underestimate the value of those things. The red caps will be available from my website shortly!
Downloads
Please feel free to use the above QR codes for the Epic Feature Story handout, the Story Mapping download cards, the two webinars that Brian Tucker did on Writing Better SAFe Epics and Features.
We hope you find the content useful and please do not hesitate to contact us if you need any help with your SAFe implementation.