This is a brand-new post from the ZenHub Blog . Let us know your thoughts below!
The modern day software team is increasingly cross-functional. Software leaders have recognized the value of having a diverse team of software experts, and teams are now stacked with talented technologists specializing in all sorts of functions. Content design, copywriting, UX and visual design, frontend and backend engineering, quality assurance – you name it.
This has resulted in a rapid improvement in not only the quality of software being produced, but also the amount.
Shipping better software, faster is the name of the game. However, the rise of cross-functional teams has created unique challenges for product owners, software leaders, and engineering managers alike. With so many different perspectives and specialities, how do you make sure all these cross-functional disciplines are working together as effectively as possible?
While the answer to this question is complex and multifaceted, we believe a key piece of the puzzle lies in how you track cross-functional work in your collaboration and task management tools, like ZenHub, Jira, and Asana.
For Agile purists, them’s fighting words. Now, don’t come for us. We know that that statement is contrary to what many Agile experts believe. But, hear us out.
We get the chance to work with a lot of teams here at ZenHub. We have the unique opportunity to see how real software teams from around the world are managing their work in collaboration tools. And what we’ve noticed is:
Rarely are teams ever doing Agile the “proper” way.
Yes, almost never. Most teams are taking bits and pieces of Agile – whether its regular retrospectives, working in sprints, or story pointing their user stories – and leaving behind what doesn’t serve their team. And we’ve seen this work well for teams. Of course, there’s always room for improvement. But we believe all teams are different and face unique challenges, so shouldn’t their approach to solving their challenges be unique too?
From my experience on Agile teams, thorough Reddit snooping, and some other research, teams are generally documenting cross-functional work in their collaboration and project management tools in 2 main ways:
- Dividing stories into functional areas: This looks like a separate story for each function. For example, one ticket for design and one ticket for development.
- Dividing stories into deliverable value slices: This looks like one central user story for whatever value is going to be delivered to the end-user. It will be passed through all the functions needed to produce the end result.
Those with formal Agile training may already be thinking it, and yes, the above describes the difference between horizontal slicing and vertical slicing in Agile user stories.
If you’re unfamiliar with the concept of slicing don’t worry, it’s a piece of cake! Literally.
Imagine a decadent cake with 3 layers. When you cut away a slice with your fork, you don’t eat the cake layer by layer, you take a small (or big if you’re hungry!) slice through all of the layers.
Now imagine each layer of a cake in a different function on your Agile team. For this example, the top layer is UX design, the second layer is content, and the third layer is development.
Taking a vertical slice approach is similar to the way you would eat a cake. You take a bite-sized slice with all of the layers. On an Agile team, this would look like one user story that encompasses all the functions required to make it a reality. Your story is looking at the deliverable as a whole.
A horizontal slice approach would be the same as eating the cake layer by layer. In Agile, a horizontal slice would consist of one story for each functional area. Like a story for each: UX, content, and engineering.
Now when it comes to real chocolate cake, you can go ahead and eat it whichever way you want. You might get some funny glances if you opt for horizontal slicing, though.
But when it comes to Agile stories, vertical slicing is often the best option. Remember this quote from the Scrum Guide?
Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. Scrum Teams are cross-functional, meaning the team has all the skills necessary to create value for each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
The goal is to have your cross-functional team operate as one. This allows for better information flow, creative collaboration, and the ability to pivot and iterate.
The benefits of vertical slicing in Agile are:
- One story serves as the central source of truth for all your cross-functional team members, minimizing information loss
- Vertical slicing encourages the team to work parallel and as collaboratively as possible
- History of progress on a story is tracked in one central place
- Allows the user story to stay focused on the end deliverable and value for the user
Tip: This also comes down to a common misconception when writing user stories. Many believe user stories = tasks. This is not true. User stories = value for the end-user. User stories are then broken down into tasks that the team needs to accomplish. This misconception is commonly associated with horizontal slicing.
There’s no fancy secret to implementing vertical slicing on your team, because it really just comes down to writing awesome user stories in general. And there are many formats and ways to do this depending on your team. We’ve written an entire blog on how to write good user stories, but here are a couple of refresher tips.
How to write a good user story:
- Ensure the end output will deliver value to your users.
- Avoid using jargon, a non-expert should be able to understand your story.
- Make sure it “slices the cake,” which means it goes end-to-end to deliver something of value.
- Avoid dependencies on other user stories.
- Make it small enough that it’s achievable in the time frame allotted.
- Include a clear definition of done, and has all the information necessary for the team to hit the ground running.
Many teams use some variation of the standard user story script “As a < type of user >, I want < some goal or task >, so that < some reason or perceived value >.”
The key takeaway to ensure your stories are vertical slices is to make one story the central source of truth, and it is passed through all the functions needed to ship it.
As we’ve already discussed, managing a cross-functional team is challenging. And while vertical slicing will help you structure your user stories, there are still a variety of ways to manage multiple functions in a collaboration tool.
At ZenHub, we’ve seen our teams manage this multiple ways and be successful. Here are a couple ideas to get you started.
Oftentimes different functions require different pipelines to track their work on their KanBan or Scrum board. In this case, you can create two different workspaces and use Workflow Automation to link them together. When a story or ticket (issue in GitHub and ZenHub) is moved in one workspace, it’s automatically updated in the other workspace. This allows different teams using different Boards to work off the same issue.
For example, our marketing team is split into several functions: Product, Growth, and Content Marketing. Because content requires multiple rounds of editing and design, we’ve split this function into a different workspace and linked it with our main Marketing workspace with workflow automation. This is what it looks like:
As you can see, Content Marketing’s workspace has different pipelines that are required to track the work on that board. We’ve linked these to appropriate pipelines in the main Marketing workspace.
If the various functions in your team don’t require different pipelines to accurately track work, but they have separate repos for their GitHub issues, you can add several repos to one single workspace. This allows you to track multiple teams’ issues in one handy location. This also allows different teams to share the same issue, which is key for vertical slicing.
You can set one repo as your default repo, then add other repos of your choice using the ‘Edit workspace’ option.
While vertical slicing makes sense on paper, it may not immediately seem like the best fit for your team. In celebration of the true nature of Agile, we encourage you to not only iterate on your product, but iterate on your ways of working. Just because something is working okay, it doesn’t mean something else won’t work better. This can be said for your processes, Agile events, and tools. Don’t be afraid to fail.
Does your team currently use vertical slicing? What are your thoughts on it?