Story Slicing example on Online Banking functionality
With this blog I wish to show how I slice User Stories. I have been in many twitter debates where people didn’t accept the fact that someone could be slicing stories without estimating the stories. I debated that I am slicing stories on functionality alone, ending with the smallest stories possible that still generating business value.
Also, some people kept on claiming that User Story slicing is the same as doing WBS (Work Breakdown Structure), which to me is about decomposing work packages and as a result something completely different.
I promised I would publish an example of my practice. Well here it is, long overdue.
I decided to use the example of an online banking application. I am starting at the highest level and will then be slicing the stories to the lowest level, focusing most on the Mortgage Account maintenance functionality. The example would be to broad if I’d provide the complete picture and I think I can manage with the one example.
A heads-up: I am not trying to be complete in below example. You could define more epics and split epics into more stories. What I DO want to achieve is to bring clarity to the how.
Update March 22nd: As Henrik Ebbeskog rightfully pointed out (see comments) I am only showing fragments of user stories in my example. This was a conscious decision. It wasn’t my intention to show how to write user stories. My example would become unreadable if I would have done this. And the point of my blog would be lost.
Many people have created great blogs about this process. Please find additional information on what user stories are and pointers to create and split them here:
The list can be endless…
Step 1 — Highest Level
At the highest level we defined 4 stories, also called epics:
These epics obviously provide a generic description of the required functionality, dealing with the core functionality, the security, additional features and the mobile app version of the functionality.
As mentioned the four epics mentioned above are kept short to improve the readability of the blog. The full stories are as follows:
- In order to simplify their bank account management the client wishes to have online functionality to view and manage several types of bank accounts
- In order to be ensured of a safe banking experience the client requires a secure online environment
- In order to be flexible the client wishes to have banking functionality on a Mobile app
- In order to meet additional needs the client wishes to see additional functionality to make online banking the best experience possible
Step 2 — Slicing the 4 epics
The first epic is split into functionalities for several types of bank products. As said I am going to focus on the mortgage account functionality.
Here I slice the epic into several topics that enrich the ‘Online Banking Experience’.
Next the important epic of security sliced into a number of stories.
Finally the mobile app epic sliced into four different options.
Step 3 — Slicing the mortgage account functionality
Below are the stories related to the view options on the mortgage account(s).
And here the stories related to managing the mortgage account(s). First two stories that also come from manage mortgage account(s) story, but won’t be elaborated further in this blog:
As you can see below I continue to focus mainly on the pay off functionality on the mortgage account. Otherwise this would be a 20 page blog and I can make my point slicing the stories for one major chunk.
The stories at this level are already quite specific, but they can be sliced even further.
Step 4 — Slicing mortgage account functions even further
We are now reaching the lowest level. The stories are now so small that there’s no room for misunderstanding anymore.
Also at this lowest level I am going to present a couple of examples of the full stories:
- In order to make sure that no illegal transactions are activated the mortgage department wishes to disable the functionality to allow making payments on mortgage types ‘E’, ‘F’, ‘G’ and ‘H’ on the detailed mortgage account screen.
- In order to have a logical user interface the client wishes to see processing of the request allowed solely after pushing the ‘Payoff’ button on the detailed mortgage account screen.
- In order to make sure that the transaction date is without errors the client wishes to have a check if the date entry on the detailed mortgage account screen indeed is in the format of DD-MM-YYYY.
- In order to have a fully automated mortgage pay off process the client wishes that an e-mail with the following payoff details (Mortgage Number, Amount, Date, …) is sent to mortgage department to process the order further when the payoff process has status ‘submitted’.
And that’s the end of the example.
I hope that this blog clarified how I have been slicing user stories looking at functionality alone. The moment to stop slicing is when I see no options to slice the functionality any further. Specifically NOT when I think I reached the point that stories are small enough to be built in X time.
And hey, I never said I was doing rocket science. I merely came into a number of discussions regarding slicing where I only could claim what I did, without anything to show. I hope this blog helps with that.
Update January 18th 2017: During a twitter conversation Peter Kretzman said the following about my example:
Indeed you could argue that I oversliced up to a level of almost pseudo code. The reason for having it visualized as I did is that otherwise this example would be too simplistic and too small. On top of that, who is to say that this kind of information -as presented on the lowest level- isn’t required to get a full understanding on the subject?
I received more feedback from Peter Kretzman and others who read this blog. Those will be answered in a new blog which will be discussing my reasons to perform a slicing exercise.
Originally published at ageling.wordpress.com on March 21, 2016.