For any kind of enterprise-wide change initiative, if you derive your backlog of Business Stories only from interviews with users, you may to end up with a patchwork of individual needs that don’t necessarily hang together, some of which will conflict with each other and which won’t give you the enterprise picture.
If you don’t already know why I say “Business Stories” instead of “User Stories”, click here for some pre-reading.
Some time ago I worked on a programme that was already in sprint 8 of its software development by the time I joined. Two large walls were plastered with index cards representing Epics and User Stories. Considerable time was spent daily on re-arranging those cards, involving at least two senior business analysts and the Product Owner. After a week, I asked what they were doing and I was told that they were trying to organise the cards so that they represented the relevant business processes. My response was something along the lines of: ‘Surely the business architecture that drove out these stories already shows the relevant business processes.’
I admit, I knew there was no business architecture and that I would get blank looks but I wanted to make an important point, which is that you should derive your initial Product Backlog from your business architecture, not try to reverse-engineer your business architecture from a bunch of User Stories.
That conversation led to another one with the Product Owner and not long afterwards I was asked to work in parallel with the software development project to help the business define its technology-agnostic architecture and use that to verify whether the Product Backlog contained the right stories.
It turned out that many of the stories were wrong, or duplicated other stories, or conflicted with other stories and that no amount of re-arranging the index cards was going to tell the over-arching story: “What is the very nature of this business for which we are spending millions on software development?”
One of the key things missing was a common understanding of the strategic objectives of the programme. I eventually managed to trace down a list of them in a slide deck attached to an email (that’s right, not in a repository where anyone could find them easily). They were poorly worded, with no indication of who owned each goal, what time frame was needed or what the business value was. In fact, a set of well-structured business goals should be the starting point of your Product Backlog.
Also missing was an understanding of the business taxonomy. The organisation involved had thousands of employees, all of whom originally came from other parts of the enterprise. To use fruit as an analogy, some said ‘mandarin’, while others said ‘clementine’, when they both meant ‘orange’, so there was some duplication of user stories that was not obvious either to the Product owner or the senior business analysts. In other scenarios, multiple groups said ‘apple’, when one really meant specifically ‘granny smith’, others meant ‘royal gala’ and yet others ‘bramley’, so in some cases there was only one user story when several were needed and, again, that was not obvious either to the Product owner or the senior business analysts. In some areas of the business it was even worse: they didn’t know whether the concepts they were talking about were apples or oranges or even whether they were fruit at all.
By the way, this lack of consistency when it comes to naming and defining important concepts is common in organisations where ‘dialects’ develop over time as the enterprise grows, especially if that growth is due to acquisition of other companies. A well-formed enterprise-wide business taxonomy is an essential lingua franca.
A robust (by which I mean mature, tested but open to change) business taxonomy will suggest many candidate Business Stories. All you have to do is look at each thing defined in the taxonomy and ask whether key roles need to be able to CRUD it and you end up with candidate Business Stories along the lines of ‘So that [business value], as a [role] I need to be able to [create/read/update/delete] a [business concept]’.
Another problem on that programme of work was a total absence of business process models, which is why the senior BAs were trying to reverse-engineer processes from the Product Backlog. In fact, robust process models suggest candidate epics and stories. You could argue that a whole process can be represented by an epic. You could also argue that a particular path through a process can be represented by an epic. Either way, once you get down to atomic activities in your process model, you have candidate stories. The role represented by the relevant swimlane suggests the actor in the story (caveat: but not always), while the label on the activity itself suggests the narrative. The only thing missing from the diagram, although it should still be accessible as part of the meta-information of the model, is the business value of performing that activity.
These are the main examples of how your business architecture can be used to drive out a candidate backlog of epics and stories. Sometimes further analysis will reveal stories that aren’t covered by anything in the business architecture, in which case you update the models of the architecture to reflect the new understanding.
How do you derive your initial enterprise-wide Product Backlog?
Kind regards.
Declan Chellar
Leave a Reply