Understand What Your Customers Want with Agile User Story Maps

Quick post to point out two other blogs I recommend you read.

User story mapping is an essential practice for every agile team. Have a read of Understand What Your Customers Want with Agile User Story Maps to get some background and then follow up with Anatomy of an Agile User Story Map for the details.

Minimise Context Switching

Often if a team picks up too much work it is because they don’t fully understand, or can’t see, the cost associated with their action. Fortunately there is an exercise you can run with a team in 10 minutes to help them see first hand the cost of context switching.

3’s & 5’s

3’s and 5’s is really simple to run. We’re going to ask the team to ‘deliver’ their multiplication tables for 3x to 60 and 5x to 80. They will go through each team member to reach that goal (value delivered).

First, ask the whole team to stand up (or run the exercise immediately after the daily standup – easy!). Explain that they are being asked to deliver 3x table to 60 and 5x table to 80, and to do so by saying the numbers out loud. The first run through they will do 3x, followed by 5x. You’ll time it.

Once they’ve done that give them another chance to improve their time for the 3x followed by 5x. Then we introduce context switching.

On the third run tell them you’ll yell out “Five” and “Three” and they need to switch the number set, while keeping their place in the other number set. Here is a short demo to show you what I mean:


So the team now knows the cost of context switching for a simple task like delivering 3x and 5x multiplication tables. Imagine the impact when you have context switching for a hard task like writing a distributed system. Phew!

Ultimately you should expect to see the team take on less work, lowering their work in progress and cycle time. You’ll deliver more value to customers as a result, and you’ll force prioritisation discussions and decisions.

Give it a try with your team and let us know how it goes.

Scale Engineering Effectively with Cross-Functional Teams

As companies grow they place ever greater demands on their IT (and/or Engineering) organisations. There are constant requests for assistance, be they from the CMO who is looking to get a better understanding of customers to the customer support team looking to keep costs stable while expanding to 24×7 support. If you’re a VP or Director of Engineering at one of these growing companies this post is for you.

So, how do we approach this problem? What is the best way to grow and scale? To address those questions and more, we need to first determine how to structure our teams. Let’s explore that now.

An IT organisation can adopt one of two approaches when it wants to grow: the functional or the cross-functional team structure. One approach will lead the IT organisation down a path that will enable them to:

  • effectively scale as the company grows,
  • minimise bottlenecks and inefficient exchanges,
  • consistently deliver high quality product to their customers, and
  • maintain a happy and productive workforce

Unfortunately, the other approach will not achieve these goals. Instead you’ll be faced with an IT organisation unable to give an indication of what they will deliver, or when it will be delivered. Your teams will be constantly churning, wasting time and resources. And, they certainly won’t be delivering their best work.

To ensure you’re headed down the right path we’ll explore both approaches and explain why having cross-functional teams is the right approach.

Functional Teams

This is, unfortunately, still a common scenario. Using this approach, the IT organisation builds teams around a particular skillset, be that design, engineering, operations, quality, databases, etc.

Functional Engineering Teams

This is the path most commonly taken as it allows a VP of Engineering or a CIO to find a Director of Design and allow them to build their team. Then that same VP / CIO will find a Director of QA and have them build their team. And so on. Although logical and easier to implement, this approach has many unfortunate downstream consequences.

Fairly soon you’ll find fiefdoms within the IT organisation. Each Director will be building out their team in the way they know best, often in direct opposition to the approach that will enable the whole company to be most successful.

The functional approach leads to barriers being built between groups, often through the use of requirements documents and/or contracts. No doubt you’ll also find significant bottlenecks emerge between groups and people start talking about their people like they are talking about cattle – not fun.

Getting functional teams to operate harmoniously and collectively, while focusing on delivering solutions to meet customer demands is difficult and not at all optimal.

Imagine the value we could unlock with a better approach!

Cross-Functional Teams

In the world of cross-functional teams you may well still have a Director of Design, a Director of QA, and so on. However, the difference is that teams are structured across functional boundaries.

Cross-Functional Engineering Teams

Using this structure, we build a backlog of projects and any team within the IT organisation should be capable of delivering on a given project. Different teams may have a different scope – for instance, imagine a cross-functional hardware team that comprises firmware, capacity planning and hardware engineering people, or a cross-functional web application team that comprises front-end HTML/CSS/JS people and backend Scala people.

In this scenario there is no need for a clear contract between Operations and Engineering as we’ve got a number of teams that can approach any given project, and each of those teams have all the people they need to deliver that project. Furthermore, having stable cross-functional teams allows us to cross-train the team members – thereby making more resilient and higher throughput teams (although that is for another post).

With cross-functional teams we proactively build teams full of people that have a diverse set of skills, and in doing so we alleviate the distrust and blame that can fester within a functional organisation.

On top of that we have eliminated the greatest form of waste in the IT organisation – the bottleneck (see Mitigating Bottlenecks below).

For best results you will want all the people within a cross-functional team to sit together, you can learn more about that approach in Building an Ideal Agile Team Workspace. Another aspect we leverage in the cross-functional model is to build a team of t-shaped people, more on that in Why Agile Teams want T-Shaped People.

Mitigating Bottlenecks

In the functional structure where we have silos for Engineering, Operations, etc work may wait on a particular function. For instance, you’ve got a lot of DBA work on and only so many people capable of doing it – blocker. This may also be due to understaffed roles or different priorities between teams. Aligning the organisation is key, for more on this see Collaborating Across an Enterprise from Atlassian Summit 2013.

With a cross-functional team we’ve immediately cut the cross team communication headache that used to take place, we can better align teams with the company priorities and we deliver more value to our customers.

Now go, grow!

So, with the functional teams you’ve got…

  • Engineering and QA teams pointing their fingers at one another, questioning who’s fault it is for the poor quality of a release,
  • the Operations team pointing their finger at the Engineering and QA teams for delivering a release that can’t be deployed, and
  • no doubt you can think a few examples from your own experience

Cross-functional teams are the best way to scale an IT or Engineering organisation. They enable an IT organisation to:

  • effectively scale as the company grows,
  • minimise bottlenecks and waste,
  • consistently deliver high quality product to their customers, and
  • maintain a happy and healthy workforce

Remember to take a pragmatic look at your organisation before deciding on an approach as you may find areas where a functional team will work best. For example, Legal is one area where I would advocate for a central team looking after all activities.

Ask yourself: can we afford to keep the current functional structure in place? To learn how to change from a functional to a cross-functional structure let us know your top concern via Twitter:

Why Agile teams want t-shaped people

On Scrum teams we often speak of ideals. While these may not be immediately attainable by the team they are things a team should strive to attain as it will assist them in becoming a high performing team. One of these ideals is a T-shaped person.

A t-shaped person is one who has breadth in a number of areas, and depth in a few. This allows that person to pick up work that, for example, includes front-end and back-end technology. The t-shaped team member may not be a wizard on the API’s, although they’ll be able to get by.

T-shaped people complement Agile teams

If we’ve got a team of t-shaped people then we’ve got breadth as well as depth in a number of areas. The team members will complement one another.

For example, we have Bob who is a t-shaped person with front-end and back-end experience. Sally is the API wizard though. How does this work in practice? Bob may pick up a story that requires an extension to the API, and he will write that. Sally may provide a code review or have included some points in the acceptance criteria to guide Bob. Ultimately they are working together to deliver value to the customer.

Cross-Functional Teams

A team of t-shaped people, each with different skills and specialities, enables team members to complement one another and form a high performing team. Teams with these cross-functional members, another way of saying t-shaped people, are higher performing as they have less internal bottlenecks and contention for one person’s time.

Of course the final benefit is that the team no longer has a single point of failure (SPOF). Should Sally leave the team then Bob has sufficient knowledge to continue on.

Want to learn more about high performing teams? Follow @VelocityCounts for the latest blogs and podcasts.

Is Burnover Preventing your Team from Achieving Consistent Velocity?

Burnover.  Another name for Stories or backlog items that are incomplete at the end of the current Sprint and fall into a subsequent Sprint.  Call it what you like, but if you want to reach your Agile Nirvana, then you need to develop better recognition, techniques for handling, and methods of prevention.  If not, then you risk introducing frustration, finger pointing and even issues with team morale.

Does this happen to others?

Absolutely.  It occurs more frequently than one might think.  No matter the experience level of a Scrum team, Burnover will occur.  For teams and organizations early to Agile, this is quite a common outcome and can hinder adoption.  I’ve witnessed many situations where Burnover was sited as an example of why Agile wouldn’t work within the organization and why they had to fall back to <insert another non-effective methodology here>.

What Causes Burnover to Occur?

Good news, it’s real simple.  Most of the time Burnover is your fault!  When I say “you”, I mean your Scrum team (the collective you).  For whatever reason, your team wasn’t able to deliver against your commitment.  The three most common causes that attributed to Burnover are:

  1. Overcommitment – This is the result of fairly classic human behavior.  As humans we want to help.  We want to sign-up for more, always.  It’s how we are wired and actually a very important and helpful behavior, but one that requires some reigning in.
  2. Misestimation – Estimation is a art and one that frankly I’ve struggled with in the past.  It requires technique, practice and a good deal of patience in order to perfect.  Experience and conscious measurement will help you get better with this.  It’s very important to recognize that certain team members will be better at this than others or gaining consistent velocity can prove difficult.
  3. Impediments – Stuff happens.  We are advancing product and technology at such a fast pace.  There are many moving parts, teams are collaborating and integrating – and because of this we often uncover surprises.  Sometimes these impediments prevent forward progress and result in Burnover.

During your retrospective, it’s important to assess each Burnover Story or backlog item, classifying it as one of the categories above.  Knowing the source will better help you prescribe a remedy.

How to Properly Handle Burnover?

Because this will happen, you best know what to do with Burnover Stories or backlog items.  First of all, don’t ignore Burnover or sweep it under the rug.  Regardless of how you feel, ignoring or hiding will only increase frustration and prolong your teams ability to achieve consistent velocity.  Here’s a quick five-step guide on how you should handle Burnover:

  1. Because the Story or backlog item was incomplete, it’s Story points do not count against the Sprint.
  2. The Story or backlog item needs to be moved into a future Sprint or into the backlog.  You shouldn’t make the assumption that it should automatically move to the next Sprint.  Consult your Product Owner and team to find out if the remaining tasks (assuming some had been completed) are still higher priority than other backlog items.
  3. Opinions vary sharply on this, but personally I prefer to “clone” each of the incomplete tasks for an incomplete Story to move to the next Sprint or into the backlog.  This way, we can report against tasks that were completed within each Sprint.  Some tooling will let you track and record this without the need to clone.
  4. Your team will need to review the estimates assigned to each cloned task to ensure that the original estimates are still accurate and the remaining time will need to be reset.
  5. Your team capacity for your subsequent Sprint with the newly added Burnover Stories or backlog items will need to be adjusted.

Tip:  I like to color-code, tag and/or label Burnover Stories and backlog items, so they can be quickly filtered from the active list of committed items within a Sprint.  It’s good to keep a watchful eye on these in their subsequent Sprint, so we don’t repeat and push forward into additional Sprints.

Tips for Preventing Burnover

Impediments aside, you can prevent most Burnover from occurring in the first place.  Prevention starts with historical analysis of your past Sprints.  When coaching teams, I’ll typically build a quick scorecards or something I call a “blame pie“.  It’s a simple pie chart that  assigns historical totals (output as percentage) against the three types of Burnover (Overcommitment, Misestimation, and Impediments).  Using this simple chart will help you focus your attention towards some corrective actions.  

Let’s assume for a moment that your blame pie indicates that the largest percentage of Burnover is attributable to Overcommitment.  In this case, then as a team you need to decrease Stories and backlog items being committed to each Sprint.  While that’s fairly obvious, what I typically see teams doing is guessing at the frequency in which to dial back their commitments.  The method that I find works best, is to have your team commit to their historical average, less the historical average Burnover.  Repeat until you are delivering against 100% of your commitments.   

What if your blame pie indicates that your largest percentage of Burnover is attributed to Misestimation.  In this case, you may need to perform some additional analysis.  To grow your teams estimation skills, you need to find out the types of Stories and backlog items where misestimation is occurring.  Once isolated, look for patterns and find a way to describe or personify the Stories or backlog items along with actions your team will take when they come across something similar in the future.  For example, maybe you find a Story that was “Way too large” and really should have been broken into multiple smaller Stories.  Develop a “Way too large” persona for this Story and describe the characteristics and the action of breaking the Story into smaller portions.  Or maybe you find a task that is not very common, but always takes your team longer than expected because they forget how “Uber complicated” the details are hidden within the task.  Develop a “Uber complicated” persona for this task and make sure you indicate that the estimate should always be higher than the initial value assessed by the team. Once you have a series of persona’s, make sure you publish them in a manor where it is easy to reference during your planning / commitment meetings.

It’s unlikely that Impediments are top on your historical blame pie.  Not to say it doesn’t happen.  I have come across this on rare occasion.  True impediments are difficult to predict and therefore prevent.  However, I do have several suggestions for how to deal with them and will discuss this in greater detail during a future post.  For now, let’s have you focus on reducing and ultimately eliminating Overcommitment and Misestimation from the mix.

Does your team experience Burndown?  If so, what are you doing to mitigate?  Please share your experiences via comments below or [email protected]

Enjoy this post? React on Twitter:

Planking and its Impact on your Agile Team

New Scrum teams may find meeting their sprint commitments hard, it can be awkward at first! In this post Randall explains what planking is and how to avoid it.

I’ve been an avid hiker since my 8th birthday, the day I got my first new pair of hiking boots. Ever since, if I have time and a trail to hike, I’ll make a go at it. By 15, I had hiked one-third of the Appalachian Trail, which totals 2,200 miles (3,500 km). I trekked North-to-South, a stretch from Mt. Katahdin located in Maine all the way to Maryland. I’ve hiked nearly all of the major ranges in North America, including my favorite the Philmont range located in New Mexico. Early on, while hiking with a good friend and lifelong mentor Yiao-Tee, I learned a very valuable lesson that not only applies to the activity associated with hiking, but one that I’ve carried forward and applied to many other personal and professional activities in my life. The lesson was: to keep a consistent pace, a continuous rhythm only stopping for physical and biological necessity (e.g., shedding / adding layers, hydrating, avoiding danger, or other must-have biological functions). This lesson came as we were ascending above tree line and he saw that I kept stopping every quarter to half mile, insisting that I was gased and needed to rest. Yiao explained that this behavior was more mental than physical. My mind was telling my body to stop and not the other way around. It was in my head. I listened and out of respect, I acknowledged – but I’ll admit, I thought he was wrong.

Fast Forward – Agile Coach

The Company:  Iconic Automotive Company
The Project: Rebuilding the legend of a muscle car in modern day
My Title: Drive fast and take chances (Agile Guy)

At the time, Agile was a very new concept. Ink on the Manifesto had barely dried. With a strong background in Lean Manufacturing and XP, Agile stuck. I’ll go as far as saying it made more sense than any software or product development methodology I had previously used. Locked away in a private warehouse with an incredible team of engineers, we began re-imagining the dream of our Father’s and Grandfather’s generation. The soft click of a key, grind of the starter engaging, the pulse the intake valve gasping for air and fuel, metal on metal as the piston compressed this mixture, a short volt and finally combustion! Sound from the exhaust that would wake neighbors or let friends know you had arrived. Ahh, the muscle car. This was now our dream to conceive, but the catch was we needed to produce working results in 18 months, roughly half the time of standard vehicle production (concept –to- launch). This was a fixed date project, with commercials, marketing and the like all lined up. There was no slipping and no turning back.

What’s Wrong with Us?

We discovered quickly that meeting our Sprint commitments was proving to be more difficult than designing and building a car. The car stuff was their job to figure out. Mine was to figure out why we were failing our plans. Our team was running two week iterations which fed into one month increments and then upstream into project phases. While staring aimlessly at our paperboards and daily burn-down charts fashioned from the back of empty pizza containers (big on hiking, bigger on recycling), a pattern emerged. It’s a pattern that many years later I coined “Planking”. It’s easy to spot and was right there all along, but I overlooked it.

Example of an agile team planking, shown on a JIRA burndown chart

The image above is a burn down chart taken from a project being tracked within Atlassian JIRA. The image depicts Planking, where there was a 4.5 day period of time with zero Stories being completed.

The Discovery

At a varying point in all of our Sprints, I noticed there was a period where no team members were completing Stories. It ranged between 2-4 days, but always present. 29 superstar engineers slowing down at nearly the same point in time each Sprint. None of the pauses were associated with impediments.

I discovered through a series of experiments that our team was the cause of the Planking. Their minds were telling them they needed to pause, break stride and slow momentum. Although everyone had a valid reason for not burning their particular issues during the periods of time, the reasons boiled down to “excuses” that satisfied their want/desire to stop and pause. The team wasn’t underestimating effort, they were Planking.

Prevent Planking

Once discovered, I brought the group together and explained the findings. I mentioned what Yiao had taught me while hiking as a child. In an effort to prevent, we evolved our process and made the following changes:

  • Instead of a Pizza box, I plotted our burn down chart on a large concrete wall using bright sidewalk chalk. We opened our morning Standup by reviewing the burn down as a team. Transparency and awareness of the chart proved incredibly valuable.
  • Instead of pulling Stories from our committed Sprint in order of Business value, we began each Sprint by working on the most complex Stories (where possible). This “eat-the-frog” pattern allowed us to work forward through each Story with the feeling that we were gaining momentum (as the Stories decreased in complexity). I’ll cover this concept in more depth during a future post.
  • I drew a large circle on the bottom of the warehouse floor, just beyond the threshold entrance and in the center I put the number of days since our team had last Planked. The entire team was forced to view each morning as they began their day, reminding them of the challenge we had put behind us.
  • We heckled our colleagues during the morning SU (stand up). Anyone who didn’t burn in a 24 hour period was forced to lean a large 2x6x6 piece of lumber (our version of a plank) up against their desk, almost like a flag indicating they hadn’t burned.

Has your team experienced Planking?  If so, I’d like to hear about it, share your experience in the comments below or tweet @VelocityCounts.

Measuring the Velocity of Agile Teams

Velocity. By far the single most important word to any Agile team. Whether you are currently practicing Agile, looking to adopt within your organization or trying to achieve your Agile Nirvana, understanding Velocity is fundamental to achieving success with Agile.

Velocity.  By far the single most important word to any Agile team. Whether you are currently practicing Agile, looking to adopt within your organization or trying to achieve your Agile Nirvana, understanding Velocity is fundamental to achieving success with Agile. Beyond a basic understanding, it’s important that you learn how to measure, influence and improve upon it. Velocity is a point-in-time metric (unit), used to accurately measure the value that your product development teams are delivering to your business.

Calculating Velocity

Calculating your Agile teams Velocity is quite simple. Just sum the total estimates (story points, days, ideal days or hours) of user stories, requirements or backlog items that were delivered and accepted within a prior Sprint (iteration). If this is your team’s first iteration you can still plan your initial Velocity. A good rule of thumb when using time-based estimates (e.g., days, ideal days, etc) is to plan initial Velocity at one-half your team’s total available time. When doing so, keep in mind that you need to account for overhead (e.g., meetings, email communication, documentation, etc.).

For example, let’s say that you are using an iteration length of two weeks and that you are working with a team of four developers. Using this example, you would be working with a total of 40-days (4 developers X 10 working days). Applying the rule of thumb above, your team would ideally plan the iteration with 20 days of work.  Using story points as your estimate?  I’ve found that using roughly one-third of total story points planned is a great place to begin for most teams.

Using Velocity Charts

Like burndown charts, velocity charts are invaluable as they provide insight into how a team is progressing with their current and any previous iterations.

Velocity Chart from Atlassian JIRA

For each iteration, a typical velocity chart will show the sum of estimates committed against the sum of estimates delivered and accepted. Velocity charts can help your teams plan more accurately. They are easy to produce, so whether you are using a tool with this feature built in or not, you should take time to produce one for each iteration.  The image above is a velocity chart taken from a project being tracked within Atlassian JIRA.

Using Velocity as a Guideline

It can take several iterations for before your teams velocity stabilizes, but from the very first iteration onward, your teams should be using the velocity of your prior iteration(s) as a guideline to help steer planning sessions and influence team commitments. When first adopting Agile, it can be difficult to contain the teams desire to overestimate their velocity. This is natural and actually something rooted deeply in human behavior. The best way to prevent it from occurring is to temper your commitments by using the teams own historical velocity as a guideline. It’s certainly okay to stretch and grow the teams velocity if you are consistently achieving and/or exceeding your commitments as long as it is supported by your historical velocity.

Keep Velocity Simple

Velocity is a fairly simple concept. It is easy to measure and track a teams velocity over time. This is actually intentional and much of the value comes from the fact that velocity is straight forward and easily understood.

Some teams we’ve worked with get this wrong – they overcomplicate their velocity measurement. One way to keep the understanding of this Agile metric pure and simple, is to write down the meaning and have it physically present above locations where a team’s velocity is out on display.

Stable Velocity leads to Predictability

When an Agile team achieves a consistent velocity over time, their velocity becomes “stable” and in turn the team becomes predictable. Teams that are predictable make it easy for a Product Owner (PO) or set of stakeholders to assess the delivery date for a fixed scope product backlog, or even a portion of the backlog such as an Epic or series of Epics.

When working towards a fixed date product release predictable teams have the confidence to make commitments to customers. They also have the ability to have a discussion about features vs time trade-offs as they have a greater understanding of their cadence and capabilities.

Predictable teams:

  • have a consistent rhythm and cadence that others don’t,
  • help to motivate other parts of the organization,
  • collaborate more effectively amongst themselves and with other parts of the organization,
  • ship product!

So, what’s holding you back from measuring your teams velocity? If you don’t measure it you can’t improve it1.

  1. William Edwards Demming []