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

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

Figure 2 - Vertical Teams working on features

Figure 2 – Vertical Teams working on

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

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

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

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

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
comments powered by Disqus