Scrum tactics

Develop your agile mindset

Steffan Surdek

Cutting through the jargon to the common sense buried beneath, Steffan Surdek discusses cross functional teams, increments of functionality, and minimum feature sets.

On Scrum projects, teams talk about delivering a working increment of functionality every sprint but what does this mean exactly?  Do teams need to deliver to a production environment every sprint?  This may work for maintenance projects, but what does this mean for new projects starting from scratch?  What kind of teams do you need to build increments of functionality every sprint?  In this article, we will discuss cross functional teams, increments of functionality and minimum feature sets.

One of the big challenges teams new to agile face is to understand the concept of vertical slicing of functionality.  It is a change in mindset that is challenging to adopt because coming from a waterfall world, teams may have a more sequential view of the development process.  Imagine you are trying to develop three pieces of functionality.  Figure 1 illustrates a typical horizontal slicing where you need to prepare the database and implement some architectural foundation before you can start delivering working functionality to the user.

Figure 1 – Horizontal teams working on features

Figure 1 – Horizontal teams working on features

Many companies adopting agile practices have development silos that exist around specialties.  For example, in a web company, you may have a team of integrators that work on the front-end side, developers that write server-side code and designers or architects that dream up the look and feel of the web site.

When making a transition to agile projects, the dependencies between these various teams will cause problems when attempting to deliver a complete piece of functionality inside a sprint.  The common mistakes these teams make are either:

  • develop their pieces sequentially in different sprints and integrate later
  • develop their parts in the same sprint as separate teams but fail to coordinate their efforts properly

Different teams developing pieces sequentially in different sprints makes it more difficult to understand when all the teams will complete their pieces of functionality and be ready to integrate and deliver them.  One team running late delivering their piece may impact the schedule of other teams.

Delivering as separate teams in a same sprint creates a lack of ownership for the feature.  The challenges are coordinating the teams working on the same feature and making all teams accountable for design and delivery.

Cross-functional teams and vertical slices

Part of the solution is to create multiple cross-functional teams, which have team members with the complete mix of skills necessary to deliver a project or at a minimum an increment of functionality in a sprint.  Using my earlier example from the web company, this means you would have multiple teams of between five and nine team members with a mix of integrators, server-side developers and designers.

Building cross functional teams allows the option of having the teams work on different projects or share a single Product Backlog but tackle different features.  For simplicity, figure 2 below shows multiple teams working on the same project but on distinct features.

Figure 2 - Vertical Teams working on features

Figure 2 – Vertical Teams working on features

The purpose of creating these cross-functional teams is to reinforce the ownership of an entire project or entire pieces of functionality by a single team.  Being together in the sprint planning and daily meetings simplifies building a common understanding of what to build and allows them to coordinate their efforts to deliver the functionality inside the sprint.

The other purpose is to force the teams to slice the functionality vertically, meaning end to end (i.e.: a working slice of functionality) instead of component by component (i.e.: user interface, server-side, design).

Before doing any coding, the team should discuss a feature and decide on the best approach to deliver something that will work end-to-end, manage risk and help them learn something useful for future sprints.

In a training class I gave recently, my students were building a paper prototype of a website over multiple sprints.  The challenge they faced in many sprints was building more into a feature than they needed from a user perspective.  In one instance, they committed to build group discussions functionality on their social media website.  Instead of keeping it simple in their sprint and allow users to create a group, join an existing group and post on a wall, they also designed functionality to manage all their groups and invite friends to a group.

Building only the most essential pieces first gives you less work to do up front and is the key to being able to deliver working functionality in a short development cycle.  It takes time to learn because it doing this goes against our traditional development habit but teams can learn to do this effectively with practice.

Figure 3 shows some example increments for an online ticket sales web site where users can buy tickets for live events.  The first increment would be for the team to allow users to buy a single ticket for a single hard coded event.

Buying a single ticket at a fixed price would allow the team to address the risk of integrating with a third-party (i.e. the credit card processing vendor) early in the project and proves the core of the system would work.


Figure 3 - Sample increments of functionality

Figure 3 – Sample increments of functionality

The next increment builds on this foundation by allowing a customer to select a ticket category and the number of tickets to buy.  These additions would prove the website could also handle different ticket prices and calculating totals.  In our example, the team would also suggest the best available tickets for the category the customer selects.

Finally, in the third increment, the team would allow a customer to select the event for which they want to buy their tickets.  This means customers would see a list of available events from which they could select one and view the event details.  From the details page the customer would use the existing functionality from previous sprints to select the ticket category and the number of tickets and would buy their tickets.

Minimum feature sets

Earlier, we spoke about delivering potentially shippable increments of functionality every sprint to allow users to begin using them right away.  When working on an existing system, it may be possible to do this, the team just needs to think through the development sequence differently.  Developing smaller increments of functionality may also cause the team to refactor their code or rework in the same areas of code many times.  The code refactoring challenge will be even greater when teams are working on updating an existing system not developed with incremental delivery in mind.

Even though you gain flexibility developing and delivering a new system it may not make sense to put the pieces in production at the end of each sprint.  For example, if we come back to our online ticketing website, our users may have no particular use for a website that only allows you to buy a single ticket from a single event.  What you really need to do is understand the minimum feature set that would make your release a usable release for users.

Identifying the minimum feature set for a release allows the team to have a high-level view of what they will need to deliver in the end.  As you can see in figure x, the term “release” represents the results of multiple sprints assembled together.

Even when not delivering to production every sprint, you still want the team to develop completed end-to-end increments every sprint. At a minimum they allow you to show your stakeholders how the project is progressing and gather feedback regularly to make sure your team is developing the right solution.

Having completed increments also allows you to minimize waste if you ever decide to stop a project early.  For the sake of discussion, let’s assume you are working on a maintenance project and delivering completed pieces of functionality to a production environment every couple of sprints. Unlike a traditional project where you deliver everything at the end of a project, the completed and deployed pieces will remain available to users even if management decides to stop investing in the project.


Cross-functional software development teams have the expertise needed to deliver complete incremental pieces of functionality inside a sprint.  These teams also feel a greater sense of ownership over the functionality they are building.

Deliver smaller increments of functionality at a time allow teams to better manage risk and also allows them to show stakeholders the progress of the project by regularly showing pieces of working software.  Switching to a mindset of delivering small end-to-end slices of functionality is one of the biggest challenges new agile teams face.

The increments the teams deliver do not need to go to production every sprint but they need to be complete.  This allows the Product Owner as well as the team to gather feedback from external stakeholders.  Building smaller pieces at a time may also force the team to refactor code in a later sprint to add more functionality to a previous increment.  For new projects, understanding the minimal feature sets needed to allow a release to be useful for users can help the team determine target sprints for releases to production.

One of the keys to delivering working increments of functionality in a sprint is building cross-functional software development teams to work on them.  Encouraging these teams to think through the purpose of a feature before coding can help them discover the smallest end-to-end piece of functionality they can develop in a sprint.  Being able to do effectively is the difference between having an agile mindset in your projects versus just using an agile development process.

This article originally appeared in the February 2013 edition of Web and PHP magazine.

Steffan Surdek is a senior consultant and agile coach at Pyxis Technologies. Steffan has worked in IT for over eighteen years in collaboration with many distributed teams around the world. In the last few years, Steffan was an agile trainer and coach in large companies such as IBM and the TD Bank Group. He speaks at many conferences and user groups about agility with distributed teams. Steffan is co-author of the book 'A Practical Guide to Distributed Scrum' written in collaboration with the IBM Scrum Community. He blogs on his websites and

Inline Feedbacks
View all comments