Agile Failed or Failed to be Agile?

Reading some posts on LinkedIn this morning got me thinking about this whole “Agile is dead” theme that seems to be in vogue.

The Agile Manifesto opens with “We are uncovering better ways…”. It was never intended to a be a static set of concepts carved in stone! The idea that “it’s time to replace Agile”, is like saying that “we tried to be better but failed so let’s blame it on Agile and do something else instead…”.

Like many ideas, Agile means different things to different people so we are not even arguing about the same thing. To some, Agile is where you list all the requirements in a backlog and then plan and execute work in 2-week Sprints. To others, it is a more abstract concept that guides how to navigate complex challenges by continually learning and adapting towards better outcomes.

This situation shouldn’t surprise us. The Agile Manifesto was born out of the practical experiences of thought leaders experimenting with new ways to approach software development challenges back in 2001. The Manifesto is very specifically about software and hasn’t changed since it was originally penned.

At its heart, when you strip away “software” the manifesto contains ideas that prove to be generally applicable to groups of humans taking on complex challenges. Here’s a summary of what I see in the manifesto:

  • Focus on customer collaboration and value.
  • Optimise feedback loops and learning to incorporate change as a natural part of solving complex problems.
  • Highly autonomous teams of motivated, empowered, collaborative and diverse cross-functional people are the basis for delivering value.
  • Its not about the process, its about the people – look after them!
  • Regularly inspect and adapt environment, processes and product to sustainably increase effectiveness and reduce product feature waste.

Observing organisations trying to survive and thrive in today’s challenging VUCA world, I would argue that all the 5 bullets above are highly relevant. If we look a little closer, we will find that many of those organisations will claim to have adopted Agile but are in fact a great distance from those bullets. So, is it Agile that’s failed? More likely, we are failing to uncover better ways…

From the lovely and much missed Jean Tabaka circa 2009 – “We should focus on organisational change, not lean or agile”.

Thanks Karl Scotland for drawing my attention to this statement in his post:

The key challenge isn’t with the ideas of Agile, its how we effect organisational change to discover improved ways of working. The tripwire is the change or transformation process – this is what typically fails! Organisational models are designed for stability and predictability, building in change resistance. Leaders have too much to lose and change threatens safety and job roles.

Organisational change is a complex endeavour. Sadly, it is often approached in a plan and top-down driven way with a start and end point. Ironically, what we need is to be Agile! An iterative and incremental change process that enables safe-to-fail experiments to emerge better practices. And, of course, the courage to make real changes to the environment, structures, roles, policies, processes, budgeting, reward and recognition systems, etc…

So, in summary, if we buy into the understanding of Agile as direction of travel to uncover better ways of working. Then the bit we need to fix, is how we change our ways of working.

COVID as Forcing Function

What is a Forcing Function?

Forcing Function: In the Agile space, a forcing function is a constraint that causes a change in behaviour as a team adapts to accommodate the constraint.

A Scrum Sprint is good example of a forcing function – the team has to figure out how to complete work in a tight timebox. If they work in a sequential waterfall approach: analysis – design – development – testing, then chances are, they will fall out the back of the Sprint with only partially completed work. The Sprint boundary forces them to reconsider how they shape work and collaborate to get it done, thereby driving behaviour change.

Face-to-Face Communication

In the Agile world we have always favoured face-to-face over other forms of communication and this is enshrined in the 6th Agile Principle:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

When we design teams, we aim to co-locate team members so that we maximise their ability to directly communicate and collaborate. If you’d asked me a few months ago, I would have told you that a co-located team will always outperform a distributed team.


And then along comes the COVID lockdown! Organisations were forced to send their people home and fully distributed teams became non-optional. A new and far reaching forcing function had arrived!

COVID as a Forcing Function

Given the enforced distribution of their workforce, organisations were forced to rapidly confront a number of infrastructural and people challenges. Our experience over the past months is that many have adapted well and some teams (but not all) have begun to perform better in distributed form than when they were co-located.

At its heart, agility is about adapting. Those teams and organisations faring better have adapted, and continuing to adapt, their behaviours, policies and infrastructure to surmount the challenges. I think many of the adaptions may well be retained and incorporated into the new ‘normal’, whatever that might be…

Digital Infrastructure

Some teams and organisations bumped into limitations in their infrastructure and policies that dramatically reduced the ability of their people to productively contribute. Examples include:

  • Severe and draconian security policies enforcing tight security, but preventing workers from actually working.
  • Mandatory use of virtual desktops and VPNs where the performance is so poor that video conferences and use of online collaboration tools is impractical.
  • Blanket ban on use of cloud based collaboration tools that sit outside of the corporate IT infrastructure.
  • Overly rigid rules usually result in people finding ways to circumvent them (e.g. using their own PC) and potentially less secure.

Rather than blanket bans and rigid rules, security has to be contextually flexible and an enabler for a distributed workforce to work effectively whilst reducing risks to an acceptable level for the sensitivity of specific types of information.

Not all broadband connections are equal! Even those living in more populous areas, have really struggled along as 2nd class citizens, repeatedly having to reconnect or unable to support video and audio.

I’m hoping that in the UK, Boris’s “Build Build Build” slogan is going to have our national digital infrastructure at its heart! Meanwhile, organisations might considering investing in business broadband connections for workers that are regularly facilitating or leading large online workshops and are currently suffering poor quality consumer Internet connectivity. Consider the real cost of a disrupted meeting versus the investment cost of better infrastructure.


The home office needs to be equipped to support extended digital collaboration. Siting on the sofa with a tablet isn’t going to cut it! The home worker must have reliable WiFi, suitable laptop, screen, keyboard, video camera, microphone, seating/standing desks, etc.

IT strategy and services need to redraw the boundary and recognise their workers home infrastructure as an extension of the corporate IT landscape.



Humans are by and large social animals. Our social interactions in a coffee break or grabbing a sandwich at lunchtime are an important part of the relationship building that collaboration and trust are built upon. They also play a key role in psychological wellbeing.

Extra attention needs to be put into non-work social interaction. Regular virtual coffee breaks with random colleagues are one approach – we’ve used an add-in to Slack called Donut for this. A bit of banter at the beginning of a meeting helps get people relaxed and talking, as well as providing a bit of an interaction fix. Having video on also humanises interactions as well as adding richness and effectiveness to verbal communication – seeing the Programme Manager’s Star Wars models on a shelf behind their head really helps break down barriers!

Motivation, focus and sense of purpose can be harder for some, removed from the buzz and life of the office environment.

Additional support may be required, adding structure to people’s days with regular touchpoints with colleagues and leaders, coaching to break down larger missions into short term tangible goals and ‘micro-plans’.


Teams that had already formed before COVID have generally been able to adapt to the distributed world, taking their existing relationships and team identity into the online world. Where a new team has been formed from scratch there have been far greater challenges to building the team identity, cohesion and trust.

Additional thought and time should be put into online team building activities to accelerate the development of the interpersonal relationships. Systematic pairing or even working in threes will also fast-track the sense of team as well as increase knowledge sharing, common purpose, work quality and collaboration.


Zoomed out! Whilst Microsoft Teams and Zoom are essential collaboration tools for the distributed workforce, they can also become a prison. Back-to-back conference calls are draining and when there’s no time for a toilet break or lunch then they create an unstainable pressure as well as reduce the time for focused work. Another side effect, is that meeting start times are delayed waiting for everyone to escape from their last call, reducing the effectiveness of the meeting and leading to it running over time.

Schedule meetings with gaps and reduce meeting duration. Rethink how meetings are run, look for fresh alternatives to watching a slide deck presentation that really get participants engaged. We use virtual whiteboard tools as platforms to create interactive meetings with far greater collaboration and enjoyment. Check out: and

The whiteboard artefacts transcend the scheduled meeting period so collaboration can take place before and after the meeting, as well as in the session.

Shameless plug… whilst we’re talking about tools, have a look at our: for online Lean Coffee format meetings.


COVID has forced us to rethink the way we work. The result is that we have proved remote working and distributed teams are viable and, with some adaptions and effort, made to work well. I suspect that a co-located team will still generally out perform a distributed team (especially if we include team formation). However that’s just one dimension and we should also factor in the advantages:

  • Potential for a better life-work balance
  • Reduced corporate office costs
  • Reduced travel time
  • Positive environmental impact
  • Removal of geographical barriers to team membership

There are number of tools and techniques that I’ve used through this period that I will continue to use even when/if I get to work with co-located groups again.

Scaling Agile Teams: Feature versus Component Teams

Agile experts will tell you the first rule about scaling Agile is … Don’t!

The ideal Agile team model is a single co-located, cross-functional team working closely with the customer. As soon as you involve multiple teams to build the same product there will be challenges and a reduction in efficiency (the amount of value created for a given investment). However, if timelines and product scale are beyond a single team then we consider scaling to a “Team of Teams”.

We attempt to structure the teams and work for maximum effectiveness by staying true to Agile principles and adopting a set of scaling patterns.

There are many potential patterns, however there is usually a fundamental choice between the Component or Feature team pattern as a basis to structure the teams.

This article will consider the pros and cons of these two approaches.

Lets start with some brief definitions of the two patterns:


Component teams are structured to match technical layers, components or services. Examples include; iOS team, Payment API, Data Services, etc. Customer and/or Business valuable backlog items are split across the teams, each contributing functionality in the components or services for which they are responsible.



Feature teams are structured to match business value so that they take end-to-end stripes of customer valuable functionality and deliver them within the boundary of a single team. Unlike the Component teams, Feature teams work across all components related to providing the business functionality.


In our coaching work, we find that most organisations tend to favour the Component pattern as the primary model for team design for reasons that include the following :

  • Specialised roles and expertise are easier to fit into specialist component focused teams and it would seem logical that people with the deepest knowledge in a given component will do the best job!
  • Related to the first point – departmental boundaries are usually easier to accommodate with component teams.
  • Clear boundaries of responsibilities for design, build, test and bug fixing.
  • Clear and well understood inter-team interfaces/hand-offs that match architectural platforms and layers.
  • Teams are somewhat decoupled so that they can work independently without breaking and interfering with each other’s work.

So, on face-value the Component pattern looks like a smart choice! Before rushing to a conclusion however, I’d recommend considering some of the challenges generally experienced with the Component approach.

Challenges of the Component Pattern

Long Lead Times
Record the time from when work on a business value feature starts through to the time it is potentially shippable. The collective delays and challenges of the points below all accumulate to produce average lead times that are often multiple Sprints long.


Additional Processes and Roles
The Component pattern looks neat on paper but in practice it requires many additional processes. These include:

  • More upfront work on architectural design so that business valuable backlog items can be chopped up into their technical components and handed out to the teams. Technical Product Owners are often added to the mix to run this process per team.
  • Once a team finishes a component it will need to be integrated and tested when the dependent components are complete. Integration and test teams are common additions.

Early Commitment
In order to design the component team structure (i.e. identify the components required) and to prepare the technical backlog items, architectural assumptions need to be committed to early. Apart from reducing the teams’ empowerment, it can also lead to later rework when assumptions turn out to be incorrect.

Dependency Challenges
Inter-component dependencies can block teams’ work so management and prioritisation of the technical backlogs to optimise the overall flow of high value work becomes a real challenge and overhead.

Invisible Technical Debt
Due to the focus of teams’ responsibility on their components, the Definition of Done is scoped to individual team output. In other words, we have a “Team Done” and then a “Done Done” when all components have been integrated and fully tested sometime later. The result of this hobbled DoD is that an invisible amount of debt is being carried, adding significant risk to the project and making forecasting metrics almost worthless (Burnup and Burndown charts are predicated on Done meaning potentially shippable).

Delayed Feedback Loops
The decoupled “advantage” of component teams can lead to delayed integration, feedback and learning. Later discovery of issues offers the choice of often expensive rework or acceptance of lower quality.

  • Problematic integration with extended effort and time to rectify, often with less than optimal joins between components.
  • Late discovery of load & performance challenges leading to delayed releases and/or poor production performance.
  • Expensive rework and potential for higher cost of ownership of final solution once in production.

Sub-optimised Design
One of the disappointments of the component pattern is that it rarely delivers the quality of architecture expected from a model where the best qualified people are working on their areas of expertise.  There are a number of contributing factors that lead to this outcome:

  • Loss of business context of the overall objective as teams are too removed from the business goals, working against decomposed technical backlog items.
  • Technically sub-optimised decisions within architectural layer that seem to make sense except when viewed from the perspective of consuming functionality or the overall system.
  • Conway’s Law: Solution architecture reflects the team structure rather than the business services it is meant to deliver


Uneven Workloads
One team can become overloaded whilst another may be scratching around for work. A secondary problem of this scenario is that teams are not necessarily always working on the most valuable items, rather they work on items that aren’t blocked by a dependency and are within the scope of their service or layer.

Finger Pointing
When bugs emerge, they often spread across team responsibility boundaries, leading to finger pointing as to which team is at fault and who should resolve the issue.


So as you may have gathered from the above points, I’m not the biggest fan of the component pattern and this if from many years experience, starting with my first attempts to scale Scrum teams back in 2005. I thought it looked like a logical approach at the time Smile

So, does that make the pattern bad? No, not necessarily! All patterns have to be considered in a given context and then if they look promising, try them and then regularly inspect and adapt. There are also many sub-patterns that we can apply to mitigate some of the issues discussed above.

I generally find the Feature team model more appropriate in most situations. This alternative pattern helps to resolve or reduce many of the challenges experienced with the Component approach, particularly:

  • Reduced lead times for producing working business aligned features, with faster feedback loops and reduction in process and role requirement.
  • Reduced dependencies and management overhead.
  • Increased team empowerment and architectural flexibility with later commitment.
  • Reduced excuses for a build-up of technical debt with honest metrics showing realistic progress, or lack of.
  • Easier to optimise teams’ workloads and focus on the highest value backlog items.
  • Issues and bugs have clearer responsibility with the team that was responsible for implementation.

However, the Feature pattern is no magic bullet and has its own set of challenges, and as for the Component approach, sub-patterns may need to be applied.


As this blog is already way longer than planned, I’ll explore some of these challenges and potential patterns in a later blog…

When considering patterns, judge them against Agile and Lean principles and see how they stack up. After all, patterns should be helping us instantiate these principles.

Some thoughts and aims when considering suitability of team patterns to your context:

  • Deliver working software frequently – with “working” validated by a DoD that is as close to potentially shippable as practical.
  • Working software is the primary measure of progress – track your Story Cycle-time, from the first work to potentially shippable.
  • Maximise team autonomy and align to business value through shared purpose.
  • Optimise feedback loops to maximise learning, validation of assumptions and reduction of risk. Not just what, but also, how long!
  • JIT – retain plan and design flexibility as long as practical to maximise the amount of information before decision commitment.
  • Maximise collaboration – reduce impediments to information flow.
  • Just enough process and roles.
  • Use process tools wisely, if they get in the way of collaboration or create too much bureaucracy then change the way they are used.




Has the Burndown Chart Burnt-out?

The venerable Burndown chart has been a central plank in tracking progress and predicting likely release dates in Scrum since I can remember. Over the last few years, the Burnup chart has gained popularity – lets explore why.


The strength of the burnup approach is in its simplicity and clarity, providing a view of net progress which helps predict when a product might be ready for release.

Propagating the net velocity helps to show when the product might become releasable – the dotted blue line on the diagram.

Each data point of the burndown tells us how much “Work Remaining” there is at that point in time, i.e. the current amount of work left to release the product. The delta, the “Burndown”, between the points is the total of:

  • Backlog completed satisfying the Definition of Done (burnt)
  • New backlog added to the Release scope by the Product Owner
  • Backlog removed from scope by the Product Owner

Burndown Drawbacks

The simplicity and elegance of the burndown also turn out to be its weakness.

Agile approaches embrace change as a positive aspect to increase the value delivered to the customer and business. So, it’s no surprise to find that release scope often changes significantly over time (usually in an upwards direction!). In a burndown chart, it isn’t clear what contribution scope change is making to net progress, often the impression is that the team simply aren’t working hard enough.

There have been a number of approaches used to enhance the burndown chart to provide deeper insight but to my mind these attempts lose the chart’s strengths – simplicity and readability (they also look ugly!).

Although a  team’s throughput can and does vary, working overtime, stronger coffee and more pizzas only has a marginal impact and is usually not sustainable on an ongoing basis. It turns out that the biggest lever we have to impact a release date is the scope. This is where the burnup chart comes in.


The Burnup Chart

The burnup chart tracks the throughput of the team and the scope separately so that the growth in the backlog is made very visible to all stakeholders.

The chart illustrated to the right shows an all too common situation where the backlog grows at a similar rate to the team’s throughput.

We can add a forecast for likely team throughput based on their historical performance.

Forecast approaches range from simple standard deviation through to sophisticated Monte Carlo simulation, modelling the team’s throughput data (Probabilistic Forecasting).

Now we add an indication of how the scope may grow over time.

This chart shows a scope forecast range from zero additional scope through to an increase at the current average rate.


The intersection of the forecasts ranges provides something we call the “Landing Zone”. If we drop vertical lines down to the x axis from the intersection points is shows the release date range from the earliest likely, through to the latest expected dates.

Working with a delivery date range is much more healthy and realistic than forecasting to precise dates.




We have found that when stakeholders see the impact of scope on delivery dates it removes some of the emotion from the debate and instead creates a healthy discussion and focus  on those backlog items that are critical to release versus those that are not.

While the Burndown chart is an elegant and simple view of release progress, the Burnup drives more healthy conversations that help shape the Minimum Viable Product. If the Burnup is used all the way through a release, it will help prevent the pressure on the team to work at an unstainable level and/or reduce quality levels to hit an unrealistic scope and deadline combination.

Agile process tooling is catching on with growing support for burnup chart functionality. If you use JIRA, TFS or VSTS then take a look at SenseAdapt which supports the burnup and a multitude of other handy charts.

Enabling an ROI Field with TFS Rippler

Why have an ROI field in the Product Backlog

The goal of a Product Owner in a Scrum team is to derive the maximum benefit from the team’s time, in other words to maximise the Return On Investment (ROI). Where the “Investment” is the cost of running the team and the “Return” is the value of the Product Backlog Items (PBIs) that the team turn into working software.

To help the Product Owner achieve this aim, they need to understand the relative business value per unit effort for each of the backlog items, so that they can guide the team to work on the items that will realise the most value for the lowest team effort. This is why it is common practice for Product Backlogs to have an ROI field which is calculated by taking the estimate of business value and dividing it by the estimate of the required team effort to implement the PBI. We then use this field as guide to order the backlog so that the higher value items, per unit effort are towards the top – allowing the team to deliver greater value in their Sprints.

PBI value-effort


Enabling an ROI field in TFS

By default, a PBI in the standard Microsoft Scrum process template does not have an ROI field so the first thing we need to do is add the field to our Team Project.

Here’s a view of a PBI in the standard Scrum process template, showing just the Effort and Business Value fields highlighted in red.

PBI- NoROIfield

Add an ROI field to your PBI workitem definition and set is as type Double and configure it as Read Only in the Team Explorer form as it will be calculated by dividing the business value by the effort field. Something similar to this should do the trick in the Workitem Type Definition XML:

Field Definition

<FIELD name=”ROI” refname=”RippleRock.ROI” type=”Double” reportable=”measure” formula=”sum”>

   <HELPTEXT>Story ROI based on Business Value/Effort</HELPTEXT>


Form Definition:

<FIELD name=”ROI” refname=”RippleRock.ROI” type=”Double” reportable=”measure” formula=”sum”>

   <HELPTEXT>Story ROI based on Business Value/Effort</HELPTEXT>


The result should look something like this:

PBI- WithROIfield

The next problem to solve is how to automatically calculate the ROI value.

The standard way of calculating the ROI field is by using an Excel view of the backlog via a workitem query, recalculating the ROI every time the value or effort changes and then manually publishing back to TFS. Not a great solution!

Step-up TFS Rippler. This add on service for TFS has a number of useful capabilities, performing field calculations is one of them. For more information about what TFS Rippler can do and how to install it, have a look at the dedicated website or other related blogs.

We can setup a couple of XML rules in TFS Rippler’s TransitionRules.xml file that will instruct it to automatically recalculate the ROI field whenever the effort or value fields change.

An example of a one of the required XML rules is annotated in the image below:


When workitems are changed, TFS Rippler executes the instructions in rules that match the workitem change event. This example matches against changes to the Effort field in PBIs that are in the eligible states listed, and then updates the ROI field in the same PBI. We need a similar rule that triggers on changes to the Business Value field.

The complete set of XML for driving the automatic updates to the ROI field are shown below:



Some things to check:

ü  We recommend testing out your changes on a test collection & project first.

ü  Backup your rules files before you set about modifying them.

ü  Remember to match the workitem and field names in the rules to the names defined in your process template!

ü  Also pay attention to where you place the rules within the TransitionRules.xml files to ensure that the rules are in scope for the given Team Collection and Team Project.

For more information on TFS Rippler checkout the website.

Getting More Out of TFS with TFS Rippler

TFS Rippler is an add-on for Microsoft’s Team Foundation Server (TFS) that runs as a background service, providing some key benefits that you don’t get out of the box with TFS. TFS Rippler automatically and efficiently updates workitems based on a set of customisable rules, triggered by changes to workitem fields or states. Here are few examples of what TFS Rippler can be used for:

  • Populate an ROI (Return On Investment) field in your Product Backlog Item or Feature calculated by dividing the Business Value by the Effort field.
  • Aggregate values from child workitems up to a parent, for example calculating the Total Work Remaining to complete a Product Backlog Item, calculated from the remaining work on its Tasks.
  • Provide a Feature’s percentage completeness,  based on the Remaining Story Points effort versus the Total Story Points required to complete the feature, aggregated from its child Product Backlog Items.
  • Automatically moving a Product Backlog Item to In Progress as soon as any work starts on its Tasks

Here’s an example Excel Feature Dashboard that is driven by a number of TFS Rippler capabilities, working in combination to show a great overview of Feature progress for all stakeholders:


Outlined in Green we have the percentage complete calculated for a Feature by a calculation that compares the Remaining Story Points against the Total Story Points required to complete the feature (calculated using TFS Rippler’s aggregation facility).

In Pink outline we have the Total Story Points for a feature calculated by aggregating all the Effort estimates for the related Product Backlog Items – this total figure is then in turn used to help derive the Percentage Complete and ROI for the feature.

Outlined in Blue we have the ROI for the feature calculated by dividing its Business Value by the Total Story Points required to implement it.

In the next few blogs I’m going to show how to make all this work and delve into a lot more detail. For more information on TFS Rippler checkout the website.

Multiple Teams with Microsoft Team Foundation Server 2012 & Visual Studio Scrum V2.x (Updated 14/5/2013)


Introducing Team Foundation Server 2012 and Scrum V2.x

The combination of Microsoft’s latest Scrum process template and Team Foundation Server 2012 brings a host of new features and much improved user experience. Most of the interaction and administration of Team Projects moves into the web interface with only rare visits to Team Explorer required.

A “Backlog” view enables the team to refine the backlog, quickly adding new User Stories and reprioritising any story by simply dragging it up or down the order. A forecast function provides the ability to visualise sprint by sprint how the team might progress through the backlog at a specified team Velocity. Sprint Planning is well supported; the team simply drag candidate stories into the new Sprint and then as they add tasks to the stories there is automatic feedback of team commitment versus their capacity.

A “Board” view provides an interactive virtual team board with state swim lanes so that the teams can see exactly what each other are working on and how the sprint is progressing. The Board view can be narrowed down by team member to aid Scrum meetings and personal work management. The user experience of the board is excellent, with low impedance changes to task states, hours and assignments with an automatic background save.


What About Multi-team Support?

All this new functionality and user experience works nicely when you have a single team working within a single Team Project. It is common though, for multiple teams to work against a common Product Backlog which requires a single Team Project. Consider for example where multiple teams are collaborating to build a product or ecommerce system. Configuring a Team Project based on Scrum V2.x template to support multiple teams is certainly possible but the behaviour of the board and backlog views makes some assumptions and requires some working around.

In VS2012 the multi-team scenario is supported in part by an area path mapping per team that is intended to act as a filter for the backlog and board views such that the teams see their own subset of data. There are a number of challenges with this approach though:

  • The area path is no longer available for Product Backlog theming or categorisation which is a major setback for those of us trying to make sense of large backlogs.
  • The filtering by area path is too binary, providing one of these two options:
    • A team has visibility of the entire Product Backlog but their Sprint Backlog view is unusable as they can’t filter out other team’s backlog items
    • A team can’t see the entire Product Backlog (only those scoped to their area path) but their Sprint Backlog view makes sense. I suspect this is the intended option!
  • Lack of complete Product Backlog visibility degrades architectural decisions and ability to work with the other teams sharing the backlog.
  • The “Forecast” feature of the backlog view isn’t effective unless it applies to the entire backlog rather than just team subsets filtered by area path.
  • Teams can’t pull requirements into their Sprints until backlog items have been moved to the team’s area path by someone else.
  • The issues above drive early assignment of backlog items to teams, causing sub optimal scheduling and flow of stories.
  • One of the teams has to be the “Default” team which inherits its area path setup from the Team Project configuration and doesn’t appear as a named team in navigation lists.
  • New Product Backlog items inherit their area path from the default team path setting, so the “non-default” teams can’t see them
  • All teams share Sprint start and end dates – generally good practice but teams working from different countries often have different holidays requiring adjustment of sprint dates.
  • It is possible to use a custom field as a “Team” field but this approach shares similar challenges as above except that it does free up the area path for backlog categorisation.
  • The custom field approach requires the addition of a team field in all appropriate work items (e.g. Product Backlog Item, Bug, Task & Impediment.

Given the challenges outlined above I have spent some time exploring a number of alternative approaches to supporting multiple teams. Here are three different patterns that work reasonably well if you are prepared to live with a few compromises. There may well be other good patterns so please let me know if you discover them!


Multi-team configuration – Area Path Pattern

If your teams won’t miss the area path as a means of Product Backlog theming or categorisation and all the teams use consistent dates for their sprints then try this pattern. This approach uses the area path to split the team’s views of the backlog but uses an additional “virtual team” to provide the teams a way of interacting with the whole backlog.


In this example, I’m going to have two teams, Team A and Team B, working together against the same Product Backlog within a single Team Project, Scrum03.

I’ve created three teams, the two Scrum teams and then a third team, the Über Team, who will be the “Team of teams” and are set as the default team – notice the bold formatting of the team name in the screenshot below:


The Über Team is the key to working around many of the challenges listed earlier, providing our teams the visibility of the whole backlog for Product Backlog refinement activities and joint planning. All members of both teams are also assigned to the Über Team so that they can use the Über Team’s backlog view. I’ve used Windows groups as security containers for my 3 groups, hence why the view above only shows “1 member” for each team.


DefaultAreaPathThe area path configuration for the Über Team should be set to the root, with sub areas included to ensure that the entire backlog is visible, regardless of whether items have been assigned to a specific team:






The two Scrum teams provide filtered views via their area path setting so that Sprint Backlog and Board views show only those backlog items and tasks committed to by each team. The area path setting for each team should be configured to the specific team path.




DefaultIterationPathThe iteration path configuration is consistent across all the teams as they share the same Releases and Sprint cadence.







How to work with it

See the screenshot below that shows the backlog view from the perspective of the Über Team, with the entire Product Backlog visible. Notice that we have switched the Forecast to ‘on’ so that we see how the combined teams are likely to progress through the backlog Sprint by Sprint.


The teams can jointly assess which stories should be considered for the upcoming Sprint and how they should be split between the teams and pulled (just in time) into each team’s Sprint Planning meeting. They will need to set each story they are going to consider for the next Sprint to their specific area path so that it will appear in their backlog and board views. Until they do this, they will have empty views! See PB06 above, it has been moved into both the new Sprint iteration path and the team’s area path.

To pull a backlog item into Sprint 1 is easy enough; simply drag the desired item to the sprint. The backlog item has to be edited though to select the team who are going to take it into Sprint Planning:




Having used the Über view to select backlog items for planning, teams can then switch to their own view so that they just get their own backlog items to which they can add tasks. Switching between the different team views is shown in the partial screenshot opposite. I’ve added some red marking to indicate the teams we’re currently interested in. Observe that the Über Team doesn’t actually have a name as it is the default team so it just goes by the Team Project name of Scrum03. In this example we are moving from the Über Team’s view to Team A’s view.





In the team backlog view, we select the new sprint and our selected backlog items should appear. If they don’t then either the area path or sprint selection may have been incorrect. In the screenshot below, look for the ‘+’ button to the left of each of the Product backlog items that enable tasks to be added in Sprint Planning.

We’re looking at the “Contents” tab in this example but you’ll notice that there is also a “Capacity” tab that enables the availability of each team member to be set for the sprint. This is what drives the numbers and bar charts that appear in the “Work” section of the contents tab – see the area to the right marked in red. With this feature we can see whether our team still has capacity to pull more work into the sprint.


Having planned a backlog item and confirmed that we have enough capacity to commit to the item, we move the state of the backlog item to “Committed” – see the red marker in the centre of the screenshot above.

Once the team get stuck into the sprint they have their own interactive “board” that allows them to track their progress and synchronise their work:



Multi-team configuration – Team Field Pattern 

This approach is very similar to the previous pattern except that we use a custom field rather than the area path to indicate which team has ownership of a given work item. From a usability point of view it is a very similar experience but with the major advantage that we can now use the area path for backlog categorisation.

The major disadvantage to the previous pattern is the amount of work you need put in to the initial setup of a Team Project to get this to work.

I’m going to try and save this blog from being the longest ever by simply highlighting the differences between the Team Field and Area Path patterns – most of this being in the Setup.


In this example, we have two teams, A Team  and Dilberts, working together against the same Product Backlog within a single Team Project, ScrumDemo04. This approach also requires the “Team of Teams” model and here we have the “Online” team setup as default team to enable an overall view of the Product Backlog.

In summary, what we need to do is:

  1. Create a Global List look up for the team field
  2. Configure the Team Project to use a custom field rather than the area path to support team selection
  3. Setup a custom field type and associated UI configuration for each work item type that we will need to set the team ownership – at least the PBI and Bug
  4. Map the teams that your Team Project will use

1. Create a Global List look up for the team field

The simplest way to create the team Global List is with the Process Editor tool, part of the TFS Power Tools. If you can’t use the Process Editor then there is always the command line and witadmin, using exportgloballist and importgloballist options along with some xml editing.

Here’s the Process Editor method:GlobalList







2. Configure the Team Project to use a custom field rather than the Area Path to support team selection

Use the command line and witadmin with the exportcommonprocessconfig option to export the CommonProcessConfig.xml file and then edit the Team mapping from:    

<TypeField refname=”System.AreaPath” type=”Team” />

to something like:

<TypeField refname=”RippleRock.TeamName” type=”Team” />

“RippleRock.TeamName” is the custom field that will be added to each of the work item type descriptions to enable team selection from the teams in the Global List.

See the screenshot below:


After amending the team mapping and saving the file, re-import the updated CommonProcessConfig.xml using witadmin with the importcommonprocessconfig option.

3. Setup a custom field type and associated UI configuration

Use the Process Editor to add the team custom field type to each of the work item definitions that you care about and then expose the new field on the work item form so that it is visible in both Web Access and Visual Studio. Alternatively you can use witadmin from the command line and edit the xml directly if that makes you happy.

3.1 Adding the team field to the Product Backlog Item using Process Editor:



3.2 Set the Rules for the field so that it can only be populated from the Global List you setup in step 1:



3.3 Configure the layout or UI of the PBI work item to expose the Team field:



And here’s what the field looks like on the working PBI:



How to work with it

The screenshot below shows the backlog view from the perspective of the Online Team (the default team), with the entire Product Backlog visible and the Forecast option on. The only difference with the Area Path model is that we now have the team set by our custom field, while the area path is free to be used to categorise the backlog.

PB View w Forecast


The teams will still need to switch views between the Online team and their own as they move to Sprint Planning and update the Team field of those PBIs they pull into their Sprint. Just like the Area Path model except that we now use the Team field instead of the area path.

PB View Dilberts


Multi-team configuration – Iteration Path Pattern

If your teams can’t function without using the area path as a means of Product Backlog theming or categorisation or some teams need to have different dates for their sprints then try this pattern. This approach uses an extra level on the iteration path that allows both a holistic view of the product backlog but also allows the teams to view just their own items at the Sprint level. There is an Über team again but its only role is to support a combined forecast view of the overall backlog.

There is an issue with this approach however, the standard Release Burndown chart that ships with the template doesn’t seem to handle the extra level in the iteration path. It is fairly straightforward to use Excel Reporting to show a Release Burndown and there is an example shown towards the end of this paper. RippleRock are working on an alternative chart that will cater for this approach and works on a daily basis rather than sprint by sprint. We’re hoping to have this report available for on-premise TFS setups soon …



As in the previous example, we have two teams, The A Team and Dilberts, working together against the same Product Backlog within a single Team Project (ScrumDemo 01). In addition to the two Scrum teams, we also have the Online Team (like the Über team in the first example), who will be the “Team of teams”.

The major differences in this approach are in the area and iteration path configurations as we will see below.

AreaPathThe area path can be freely used to categorise the Product Backlog as per the example shown here.

This is the configuration for the whole online team. The team area path configuration can either match this or you can configure subsets for teams specialised to a part of the system. Obviously in Scrum, we encourage good cross-functional teams but in technologically diverse systems this is occasionally necessary.

Notice that with the area path selection, it can be configured such that sub-areas are included with the parent so that all the children are also accessible to the team. This functionality is not available for the iteration path.



TeamIterationPathThe iteration path has additional level for “Team Sprints” under each of the standard sprint nodes.

This enables individual sprint start and end dates and also provides the team filtered data we need to drive the backlog and board views.

By default, new Product Backlog items are created at the node set to be the “Backlog iteration” for the default team, or Über team in our models.

To scope backlog items for a release, simply move them to the Release iteration path node – Online MVP in this example.

We are looking at the A Team’s iteration path configuration and we can see that they are set to only be able to see their “Team Sprints”.


UberIterationPathHere we see that the team of teams view is configured to only see the parent sprints and not the individual team sprints. This is important as it will enable a nice combined team forecast on the overall backlog from the team of team’s backlog view








How to work with it

See the screenshot below that shows the backlog view from the perspective of the combined team of teams, with the entire Product Backlog visible. The Forecast feature is showing how the combined teams are likely to progress through the backlog sprint by sprint, based on the parent sprint nodes rather than the individual team sprints.



From the team specific backlog view we see only the sprints for that team but we also see the entire backlog. In the screenshot below, the team are dragging a backlog item into their sprint for planning.



The other team will also see the entire backlog, including those items that the A Team are planning – as you can see from the iteration path which is indicating which team has each item. Teams can pretty much stick with their own view for planning and working through the backlog and really don’t need to keep switching to the team of teams view as we did using the area path pattern.

As we can see from the A Team view of their planning, all the new backlog and board features work as Microsoft intended them:



The only wrinkle is that the Release Burndown report doesn’t cope with the team sprints. We will be making a day by day Release Burndown report available but it is really easy and quick to use the Excel Reporting capability of TFS to build one like this:





All three of these patterns are quite workable for supporting multiple teams within a single Team Project with a MS Scrum V2.x process template. My thoughts on each approach are:

  • The Area Path model is my least favourite as it sacrifices a key categorisation facility and also offers a clunky user experience.
  • The Team Model is a better model but it requires quite a bit of setup work and shares the same issue of user experience as the Area Path model.
  • My personal favourite is the final pattern as it frees up the area path, has great flexibility of sprint configuration and a better user experience around Sprint Planning.

I’d be very interested to hear your opinions and experience too.