SYNOPSIS

There is a lot of confusion amongst scrum practitioners on what a theme is.I have seen articles that talk about the theme for a sprint (I see a sprint theme as a goal.) I cannot say that this is incorrect as it depends on the perception of the individual. This article provides you with my perception and understanding of what a theme is in scrum and how effective they are.

THE BIRTH OF THEMES

So where do themes start. During the pre-game phase (project initiation, or whatever the term is you want to use)  we collaborate with stakeholders, parties that will manage the ROI and knowledge experts. At a high level they provide us with the information on what business value they want us to deliver (you could call this scope) and the associated high level context. We then look at these and group common needs / behaviours into a set of themes.

In Feature Driven Development (FDD) these are called Subject Areas.

REALISING THEMES

So lets take a quick example, to try an convey my understanding:

We meet Fred our product development manager and Mary our domain expert, they want to deliver a new product to enter the market. This product will compliment companies using scrum and provide a basic toolset for managing the scrum method. From our high level discussion the following items appeared on a whiteboard after a brain dump.

• Program Reporting
• Register / Close projects and allocate to Program
• Project Budgetting
• Resource capacity planning / actual
• Recording resource capacity during sprints
• Adding / Removing backlog items
• Status of backlog items
• Velocity Charts
• Planning
• Sprints – Allocating / Removing stories
• Sprints – Sprint Burndown Chart
• Project – Parking Lot Report
• Project – Product Burndown Chart
• Scope management
• Allocating backlog items to releases
• Release Burndown Chart
• Goals – Themes, Sprint, Releases
• Project – Goal
• Distributed Teams – Story Wall
• Tasks for Story (Add/ Update/Remove)
• Sizing backlog items
• Ideal time for backlog items
• Backlog items allocated to themes
• Add / Update/ Remove Themes
• PMO Report Generation
• Tracking waste during project
• Impediments
• Risks
• Export of data

The above pointers where quickly extracted and gives us a high level of what they envisage. So now we look at these and create our themes. There is no right or wrong way for theme realisation, over time project experience and learnings will make things clear.

So we look at the whiteboard output and look for common behaviour.

From the above we come up with the following themes:

• Managing Resource Capacity
• Managing Product Backlog Items
• Managing a Sprint
• Managing a Release
• Managing Impediments
• Managing Risks
• Managing Themes
• Managing Waste
• Managing Data Exports
• Managing PMO Reporting
• Managing Project Details
• Managing Project Budgets
• Managing Program Details

Themes are an important prioritisation artefact. Senior executives dont like detail, themes are a good mechanism for getting prioritisation and identifying MMF (Minimal Marketable Features) for initial production release. For example: we can go to market without Managing PMO Reporting and Managing Waste.

From the above list of themes, we have a 30,000 ft view of the product and it was realised without much effort. The key here is to keep it to a high level “what” i.e. focus on the breadth of the product NOT the depth. Depth first will just lead to complexity confusion and slow you down. Themes give us that product breadth.

THEME ACCEPTANCE CRITERIA

Next we want to provide some high level acceptance criteria for each theme. This gives us the theme boundary (scope, but I hate that word) and it can be used to convey a quick overview of each theme to management, project members and interested parties. We take our dump and ensure that we have covered each one. So lets take Managing Resource Capacity.

How you do your acceptance criteria is up to you, some people use GWT (Given When Then) an ubiquios language for BDD (Behaviour Driven Development), others simply use bullet points or narrative form. I am simply going to use bullet points in this example.

THEME: Managing Resource Capacity
Acceptance Criteria

• Register / Remove Team Members for Project
• Allocate planned hours available for each team member for sprint (Incl Annual Leave)
• Record absenteeism during sprint to realise actual team capacity at end of sprint

The above gives us some context of what this theme is and what value it will exhibit. Theme acceptance criteria is important for:

• breakdown (decomposition) into epics / stories (some people are anti-novelists and use the term ‘backlog item’, choice is up to you.)
• allows us to validate that our breakdown meets the theme acceptance criteria and we have not missed anything
• allows us with the minimal amount of information to gain enough knoweledge to size (estimate) our themes

Executives etc are busy people, you have a better chance of getting agreement /rapid feedback at the theme level acceptance criteria than any other detail, once the acceptance criteria is agreed then the scrum team or teams can be left alone to decompose the acceptance crtieria to deliver the theme. Epics (Feature Sets in FDD), Stories (Features in FDD), Product Backlog Items are at the implementation level. This also leaves the product owner / scrum teams to decide on the best way to breakdown a theme.

Why must epics, stories, backlog items belong to a theme? At the micro-level (looking into the scrum) you may not care, but at the macro-level (looking out of the scrum) you are going to need to answer questions like:

How complete is the Managing Resource Capacity theme? (remember you may have different stakeholders across themes)
Lets move Managing Waste to Release 2
How much change has there been in Managing Project Details
We have decided to decompose Managing a Sprint into 2 new themes: Managing a Sprint / Managing Sprint Reports
What are the stories / epics for Managing a Sprint
What is the size of this theme?
What is the planned cost to deliver this theme based on our current velocity?
By how much has the Managing Project Details size changed, and why?

What you decomposed a theme? Yes, themes can be decomposed, what we initially started off may not make sense later. New themes can be added, split and removed.

Themes do not have to be completed in a sprint or release, I have seen practioners trying to fit a theme into a sprint and end up with hundreds of themes.

Themes are also sized (in points) this gives us an initial project sizing. I think theme sizing is an important technique, I have seen to many agile implementations where a product backlog is decomposed to story level and sized so that they can get the project magnitude, product backlogs with 700 stories at sprint 0 is a waste OR:

• I have seen agile teams say that just fund us for 3 sprints and we will see how we go i.e. incremental funding
• We cant give an indication of what it may cost, this is agile you must just let us go and see what happens

Yes incremental funding would be ideal, but in the real enterprise world, try and do it, there a vendor contracts, resourcing contracts and senior executives want some idea on costs / feasability.

I will be writing an article on theme sizing and planning in the coming weeks.