Introduction:
Collaboration magic is still missing from many agile team’s processes. Traditionally, developers worked independently and often didn’t have high collaboration with the business, QA’s, UI/UX, or with external customers. They treated those roles as “phases” that happened before and after development in a step-by-step phased approach. As a developer if you’ve worked in a low-collaboration environment that practiced phased-gate development (business requirements-> design-> development-> testing-> release/maintenance) you’ll find it very frustrating that there is a lot of back and forth towards the end of the cycle… the last mile takes so long. With a newer agile approach, we’re supposed to work in a much more collaborative environment but sometimes old habits die hard and actually prevent collaboration. How we “used to break up the work” remains the same and conflicts with this collaborative magic. Here’s a suggestion when breaking up your work to allow for high collaboration to happen.

When working on a user story try to divide the work up into pieces of a cake, a “slice of the cake with all the layers present”. If some layers are complex you can even mock them out (fake it) assuming they are implemented for the sake of getting early feedback. Getting feedback early and often (and doing desk checks) is how we can work on an agile team with many contributors collaborating to finish the story and deliver value to the customer.

A “piece of cake” is a vertical slice of the story – it includes all component layers like database, repository, domain (business layer), controllers/view, with front-end UI/HTML/CSS if you’re on the web. See diagram below that describes a typical epic story (cake) and how to deliver it via fully functional parts (slices of a cake) with all the component layers. Breaking up a story (the cake) into vertical slices instead of horizontal slices (the components) allows you to get quick feedback from your team as well as customers.

How to approach it:

• Concentrate only on the most important business value first (something a customer will use 80% of the time, skip exceptions, skip things that customers only use sometimes, skip doing all aspects and filling in the rest once you get something that is a proof of concept, something you can show and get feedback on. In technology spikes this is called a “tracer bullet”, it is the quickest way to get a proof of concept.
• Only include a few fields (the most important fields that pertain to the work at hand). For example if a form has 15 fields only implement the 3 that is most important to get the form submitted so it can go onto the next step.
• Only include a subset of the feature (remove validations, hard code some settings, remove unimportant aspects)
• Build only the most common workflow, or “work on the happy path scenario first”, then add other less common workflows later.
• Mock complex layers or third party integrations in your first slice, mock it until you get around to working on it. But remember it’s good practice to learn these complexities earlier on so if you can get the feedback you need in the first slice then implement these complexities during the first 33% of the story work would be ideal.
• Create “Walking Skeletons“, a term coined by Dr. Alistair Cockburn where you create a small implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. From there the architecture and functionality can evolve in parallel.

Benefits of doing this:

• Speed – Speeds up the feedback loop. Hand-offs are slow, collaboration is fast, opportunities are given to the team to adjust at smaller intervals as you work towards the final output. Rework is costly when you have a large output, but will be small as you increment those changes throughout the development process.
• Agility – Allows us to change if we’re going in the wrong direction. Sometimes you’re going in the wrong direction and you’ll be wasting time if you don’t do desk checks early enough so you can quickly adjust based on feedback. Having something demonstrable allows you to get this feedback early if you’re on the wrong track.
• Collaboration Magic
  • Allows QA to do desk-checks earlier. QA team members don’t want to be the bottle neck at the end, which is often the perception because when developers build layers there’s not much to test until significant layers have been 100% coded. QA’s can also start their functional automations a lot earlier as well so they’re not writing automations for the previous completed sprint, which is often the case if you have low collaboration.
  • Allows UX to do desk-checks earlier. There are good tools to mock UI’s that have user interactions built-in. But the UI layer mockups is only a start, it’s limited to all the user interaction feedback that UX professionals need to get when the software is actually running. Eg. Have you ever seen a workflow that calls to an external API that takes a little too long? You might find that adding a progress bar or some loading/waiting prompt is easier than asking the third party API provider to make changes to their infrastructure. This insight only comes as all the component layers are connected to make a “slice of the cake” and you get functionality that supports the interaction design that you need.
  • Improving team performance, via this collaboration practice, pays off exponentially compared with improving individual performance. This is a whole separate discussion topic which you can read here.
• Product Learning –  Learning not only happens quicker within the team and the technology, it gives you opportunities to actually show customers and get valuable feedback much earlier than waiting for the entire 5-6 slices of a story to be complete (as is the case when building components). Your UX and Product team often have pilot customers or customer advocacy groups that love giving feedback and input on the things you’re working on. These early adoptors of your features or stories can help you steer the remaining stories on the right path so that you’ll have less rework if you were to show them the “entire cake” many months down the road.
• Deliver Quicker – Allows you to deliver completed work even if the entire story is not 100% complete. Eg. If your cake was made up of 4 slices and you delivered 3 slices (75% done), it’s still valuable to a customer cause they can perform 3/4 of the story completely. Contrast this approach to delivering 3 layers (domain, repository and the database layers) that doesn’t provide value from a customer perspective (the UI that they need to interact with is missing). Even if you’re 90% done, without a UI you might as well be 0% done. In the first scenario you’ve delivered 75% of working features, in the 2nd scenario you’ve delivered nothing to a customer because they can’t use anything. Creating a “walking skeleton” is better than having a full body with no head or brain to control the rest of the body parts. Remember that delivering value to customers might be different depending on where the product is at in the technology adoption life cycle so release with that in mind!
• Lower Risk – Technical risk as well as story complexity can be identified earlier for the story, not just at the end when you finally connect the last layer to find out that you have complexity in one of the layers. Or finding out that your most complex layer is the last layer you decided to do last and that work requires a bunch of extra time, ruining your teams estimates. The complex component is discovered quickly because it’s part of the initial slice you work on! It’s great to be able to identify risk earlier on in a sprint which helps you more accurately scope the remaining work required, making your team and Scrum Master very happy!

What to look for if you’re doing it wrong?
As a developer, how do you know you’re not doing this correctly? What are the smells to look out for if you’re doing it wrong?

• At standup you say you’re working on the same story over and over again, but nothing is ready for desk checks from UX, QA, Product until you’re really far along.
• Take note the scrum/kanban/agile board that you’re using, are your stories moving incrementally every day?
• You’re half way through the story and you’ve not interacted with QA or UX or gotten much feedback from the product owner. You should actually try to get this earlier even at the 30% mark, it’s possible if you break up and work on the “slices of cake”.
• You find that QA or UX is always giving feedback way to late in the game and the story completion is always at risk, causing you to rush last minute feedback from other team members at the end of the iteration.
• Rework. When you do get feedback it causes you to change a lot of code or logic. This means you went too far without getting feedback, undoing code or adding a lot of logic to get the new feedback implemented is a huge sign of not following this approach. If you build it lightweight, just enough to get feedback then changes that you get from the feedback should be small and incrementally forward moving.
• Does QA or UX or even product team members always seem like they’re the bottleneck to being able to say “we’re done” to a story? Most of the time, it’s because they were involved too late in the process!

Now you can change this!

Rule of thumb
Although this is not always possible, having the mindset in place and practicing “slicing the cake” or creating “walking skeletons” will help you work on a team and deliver better results because you enabled early feedback and collaborated with other team members. So instead of throwing the work over the wall or waiting until you’re fully complete your part of the process (limitations of the old process). In my experience 95% of the time it should be possible, so use that as rule of thumb!

Additional references…
Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

~ Bill Wake

http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake

Related to user stories but can also apply to working on an architecture story or a technical spike, AKA the concept of “tracer bullets” from the pragmatic programmer http://wiki.c2.com/?TracerBullets.

It’s a best practice to use the INVEST mnemonic https://en.wikipedia.org/wiki/INVEST_(mnemonic) when creating or breaking up user stories into smaller manageable parts. This practice aligns well with creating “walking skeletons” and working on “slices of a cake”.