So often lately I’ve seen a lot of posts focussing on how to split stories, how they should be structured, and techniques for getting them into a certain state. What I haven’t seen are posts explaining the benefits, and the reasons why stories that are planned as a total slice through a system are a good idea for our development teams.
Firstly, I’d like to ask you a question: How often do your teams miss a sprint goal because of a front to back end dependency? Front to back here can be UI to API, or API to DB. Do you hear the excuse: Well the API changed and we didn’t have time to implement those changes? It’s an excuse that I have used, and that I’ve heard my teams use in the past.
The idea of slices through a system, is not a new idea, but it is one that is difficult to achieve without good planning and patience from your Scrum Master and development team, which, I was lucky enough to have in my last lead role.
I want you to think of your system like a piece of extravagant Victoria sponge with three or four layers of cake. Next I’d like you to think about how it can be cut in different ways to be manageable. You could cut it layer by layer into small bite size pieces and that would certainly be consumable, if you think you could fit six small pieces of sponge in one sprint, then it probably also fits the goal of small enough stories. But what if the aim is not to consume the sponge, but to reconstitute it, so that it all fits neatly together again? If you took it in small sections layer by layer, you would find it very hard to put it all back together, so that it was neat and presentable. Imagine what this would look like if you deconstructed the entire sponge!
Now take a new sponge of the same extravagance. Take a very thin slice all the way through the sponge. You don’t need to try to fit it all together, as it came as a connected piece. This is how we need to get our teams thinking when it comes to our stories. A great question to ask our teams is: If this is the only story you complete this sprint, does it deliver something to our users?
This something, may be just one button that they can click, that doesn’t necessarily do a lot for them on its own, but it fulfils the following criteria:
- It works
- It is useable
- It is displayed from the UI, and goes all the way to the bottom of your system (typically a database)
The aim of the sprint is to deliver working software, and this you have achieved. You still may not always achieve your sprint goal, but you start to reduce the dependencies and risk between different layers of your system.
The one thing that really motivates a development team is delivering working software. Nothing feels better than deploying something, and watching it work. I can tell you now, it’s a great feeling when you can deploy every story, and watch every deployment start up successfully, and for people to use the software you have just created.
One great way to ensure that your system entirely works, for every deployment is to pair your developers across disciplines. If your front end developer pairs with your back end developer to create an API, and your back end developer pairs with your front end developer to create the UI, you can almost guarantee that the solution will work. Although they may not be familiar with each others tech stacks, the underlying principles are generally the same. It’s also a great opportunity to cross pollinate a little knowledge about both sides of the same coin. If you can get your infrastructure engineers to pair with all of your developers, then each person knows how to deploy the system.
All of the above starts to de-risk the teams reliance on a single point of failure, which in turn de-risks each and every delivery the team will make.
Of course the biggest benefit here, is that if there is a weak point in the architecture or design, then it’s picked up at the earliest point, and can be rectified at very little cost.
As An Aside
I think it’s important here to mention “cross functional teams”. A discussion I recently had, is that I have no problem with cross functional teams, but that does not mean that every person in the team is cross functional. Generally, in the world of development, each person in the team has a specialism, whether they are UI, Backend, DB, Infrastructure etc. Whilst it is useful that each member of the team can fill in if a person is away, it needs to be understood, that not everyone will have the same level of expertise as the expert in the team. T-shaped people, in concept, is a great idea, but we have to be careful not to push our team members too wide, or stretch their capabilities, and remember what we hired them to do in the first place.