Why project executions are unpredictable?
Imagine….
... you run a company that creates a product or a service for a market.
... you have a dedicated team that works on the product
... there is a roadmap, a plan. With it, there are expectations… Expectations by stakeholders, by the team, by customers, by you
... if the plan is fulfilled everyone will be happy, there will be celebration, there will be a lot of pats on the back, there might even be some financial stimulation
Now stop imaging!
Everyone seems to be doing their best, but things don’t follow the plan. Features are late, milestones are missed, deadlines are postponed. But the worst part is that there is no rhythm, there is no predictability! Whatever the team plans, whatever you promise to stakeholders, whatever buffers you include in your plans, it simply is not enough. It shakes your confidence, it devastates the trust the stakeholders have, it completely ruins the morale of all the people working on the product.
Missing deadlines is a nasty thing, but the worst nightmare of everyone who is in any kind of delivery business is the lack of predictability. It is, therefore, worth investing the time to understand where it comes from.
There are several reasons why the delivery becomes unpredictable, and why you can’t say when the feature will be ready:
- Understanding what is being built is low
- Inexperienced team working on a product (by the team I mean all people working on it, be it designers, developers, product people…)
- Issues in the working process
Let’s go deeper into the first one. Obviously, understanding the problem we are solving is an important step in finding the solution. There is an array of things that contribute to low understanding, however, one is particularly interesting, inappropriate size of working elements.
Let’s use a banal example:
If you were to copy the whole Bible (or any other book for that matter) would you be able to estimate how much time is needed?
The chances are you have never had to copy the Bible in the past, so you definitely won’t be able to tell how much time you need for the task. Although you’ve been writing different things most of your life, and you are doing it on a daily basis.
What you CAN assess is how much time you need to copy one page, or even better one line of text.
The point is we are much better at estimating smaller parts of work. Better estimation gives us higher predictability of the output, or when our job will be done.
Predictability problem
Now, with previous biblical conclusion, let us get back to more mundane things like project delivery.
We are creating new things, new products, new feature… Although they resemble something we did in the past, they are not clones of past things. The context in which we are working has changed, WE have changed, meaning our past experience is not an ideal guide for estimating time needed to finish the work.
What we should do instead of just relying on previous experience, is chunking a project into smaller pieces, smaller tasks that can easily be estimated.
Here you can say – the user story is small enough so it should be estimable enough. True, IF it is small enough. Quite often teams are struggling with the size of the user story.
In size of the user story lies the root of the predictability problem.
In order for the team to be predictable, and to be able to give estimates, their working chunks have to be small enough to allow good comprehension of the problem, and consequently precise estimations.
So, how do we achieve small user stories?
Splitting user stories is not easy.
Firstly, the one who is writing user stories tends to write them so that they are small, by his or her standards. A colleague of mine once told me that the first user story he has written was: “Create a video streaming app.” You see the problem?
Secondly, once you split the original story, all new stories should satisfy “INVEST” principles, namely, they should all be – valuable. This means that splitting the user story into layers (backend, frontend) doesn’t make sense, as the pure backend doesn’t have a value. To get back to the book example, it would be the same as saying let’s copy the page numbers first, then we will copy the first sentence on the page, and then… There is no value in blank pages containing only page numbers.
So, we have to ensure that each new user story cuts through the whole requirement, i.e. that it creates sense for stakeholders (don’t forget that users are also stakeholders).
Story splitting approach
The Spidr1 is the acronym for a collection of 5 different techniques that can help you in story splitting.
SPIKE
Spike is the activity intended in acquiring knowledge about some problem. In this case about the user story in question. It requires time, so it is a good idea either to do it before the story splitting workshop, or after it if all other techniques didn’t show to be useful.
PATH
This technique tends to split stories based on paths that could be used by users of the application. It is usually used if there are different ways to perform some activity. For example if you can log-in using username and password, or using Google account, or using fingerprint, or using certificate on the ID card. Each method of logging-in can be a separate user story.
INTERFACES
The Interfaces technique splits user stories based on different interfaces that should be implemented. For example if your application should be delivered on computer, tablet and mobile phone, these could be separate user stories.
DATA
This strategy helps us split user stories based on the data that is needed or provided by the application. For example, if your app should segment customers based on different characteristics you can have one user story that creates segments based on the place of living, another that utilizes their age, and the third one that segments customers based on their yearly income.
RULES
Rules is the last technique in this framework. It utilizes business rules and technology standards to split a story. You can skip a business rule that is creating complexity in order to create a feature, and then, subsequently add the skipped rule. Of course you won’t be using the feature in production till all critical rules are done. Also sacrificing performance, allowing things to work slower then they should is acceptable approach in story splitting. This doesn’t go into release, but you can get feedback from internal stakeholders.
Just a few tips
Tip #1 Teamwork
Don’t forget that the main reason for splitting is that the story is too extensive for the development team to estimate it. This is why splitting should be done together, so that everyone is aware of the reasons for splitting, what has come up from the original story and why.
Tip #2 Ask questions
Ask developers to explain where the complexity lies, what makes it hard to estimate. Usually, answering this question gives a good basis to start thinking about the line where to split. For instance, if we are working on an in-app tutorial for using that app, the team might say that the complexity comes from using pictures in the tutorial because they have never done it before, they are not sure where to store the pictures, what should be the proper image size… In this case we might consider splitting the story along that line. In other words we might go with the user story delivering a tutorial with text only, and the other one where we add pictures to it.
Tip #3 Magic of numbers
Have in mind that splitting user stories doesn’t mean that new stories should have the same total number of story points (in case you use them) as the original story. Splitting stories is not about magically decreasing the number of story points, but about increasing predictability of delivery. In other words, having one user story that has been estimated with 8 points that keeps being worked on through two consecutive sprints is less worth than having 4 user stories estimated at 3, 3, 2, 3 points that will be finished in one sprint.
Now think about this….
... and start creating smaller user stories, start splitting those that introduce insecurity, extend execution and disturb steady pace and predictability. Split with your team and investigate the sources of complexity!
Author: Predrag Rajković
As I already mentioned: Splitting user stories is never easy. Here you can read more about the Agile Requirements & User Stories, but please, don’t be afraid to ask for help!