Telling a story on redefining how a software team manages incoming work.

1. I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
I send them over land and sea,
I send them east and west;
But after they have worked for me,
I give them all a rest.
I let them rest from nine till five,
For I am busy then,
As well as breakfast, lunch, and tea,
For they are hungry men.
But different folk have different views;
I know a person small—
She keeps ten million serving-men,
Who get no rest at all! She sends 'em abroad on her own affairs,
From the second she opens her eyes—
One million Hows, two million Wheres,
And seven million Whys!
The Elephant's Child - Rudyard Kipling

2. Sipping From The Firehose
~ or ~
How do we strike a balance on incoming work for SoC?

3. Multiple streams of work
We have at least 7 sources of potential work
 Support issues
 Jira
 Stuff that makes us sad
 User voice Requests
 Sales Requests
 Product Management / Market needs
 DLM Needs
(we also have uninstall feedback that we should route back to support if users provide an email address)

4. Wrong Format
Requests come in as technical requirements & features
And we’ve proven that doesn’t work for us
(or more importantly for our customers)
We need to translate back to user needs and benefits
(Even for tech debt type work!)

5. So…
We need a way of doing the right things at the right time for
the right people in the right way.
There is no panacea for this
But here’s a starting point for now

6. Prioritisation?
Without clear, absolute priorities how do we know what’s right to do?
Source, Value, impact, size, complexity, delight, damage – many criteria
Who, What, Why, Where, When, How
We don’t have a fixed answer so we need a simple way to balance our efforts

7. Simplification
Or an attempt at least.
 Support issues
 Jira
 Stuff that makes us sad
 User voice Requests
 Sales Requests
 Product Management / Market needs
 DLM Needs
 “Fixes”
 “Achievables”
 “Features”
In the words of Jack The Pumpkin King, “let me explain”…

8. Fixes
Driven by: Customer support + Jira data
Size: Variable (but mostly small to medium)
Team: ~2 team members (on a staggered 2-week rotation)
Analysis needed: Usually technical – replicate issue, try fix, validate with customer(s).
Priority: On-demand
Support issues & customer bugs
What:
Review and fix incoming support issues
Work on a continuous queue from Jira (e.g. the top 5 most reported bugs in the last 3 months plus the top 5
newest/most recently hit).

9. Achievables
Driven by: Team with occasional review from product management.
Size: Variable (but mostly small to medium)
Team: 1-3 team members per item. (~1 item active at a time).
Analysis needed: Limited - technical spike, sanity check with customer(s), check size and edge cases.
Priority: Negotiated relative to support and feature work
Tactical wins
What:
Team-led improvements to the product that have a direct impact on the user
These may be cosmetic, functional, reliability, performance
Backlog built up and prioritised by the team
Do small-medium things and do them well, (don’t do “big” stuff badly)
Prioritise teamwork over individual work
The team agrees what we’ll do
Allow us to deliver a stream of frequent releases with customer value
Maintain a pipeline of the “top 2” things the team want to deliver for our users
Ship frequently

10. Features
Driven by: Product management
Size: Variable (but mostly small to medium – we’ve lost our appetite for really big stuff but are hoping to regain it)
Team: as much of the team as can sensibly work on it at a time
Analysis needed: Feature lead* and UX collaborating with product management and customers.
Priority: Generally higher than anything but customer escalations.
Strategic changes, additions and improvements
What:
Improvements of varying size that take us toward product, division and company goals
Led by customer requests, market demand and product management expertise.
Require functional, technical and user analysis to translate from request -> need/goal/problem -> options ->
story backlog
Will typically build their own backlog of stories

11. Hang on a minute!
Did I see “Feature Lead” there?
We need more doers, not managers.
The Analysis Miracle…

12. Analysis
Driven by: Product management
Size: Variable (but mostly small to medium)
Team: Feature lead* + Product manager, UX (+whoever else can provide support & expertise)
Priority: Occasional - Whenever queue of “ready” features has less than 2 items
Lead-in work for features
What:
Taking incoming requests/ideas and translating to user-defined problems, goals and needs
Taking user-facing problems and identifying alternative options, solutions
Validating and scoping options/solutions
Understand impact across support, sales, marketing etc.
Preparing a team-facing backlog based on best selected option
Feature Lead*
The person responsible for getting “stuff” from a user-defined-problem to a state where the team can start
work on it.
Becomes the “expert” during development in order to help us make fast decisions
(sometimes they’ll be wrong!)

13. Stuff we have and haven’t answered
Q: Who will be a feature lead and what will they do?
A: Volunteers where possible. Actual work to be done will vary on a per-feature basis.
Q: What happens if we want to do more of X and less of Y?
A: We negotiate between ourselves, Michelle and David and flex around what’s most important, valuable etc.
Q: What about my pet feature / bug / idea?
A: If the team agree it’s the right thing to do now, do it (ideally with someone else). If it’s too big, less important
etc it needs to fit in with other work. (Don’t stomp on other people’s time without agreement first.)
… that’s fine we’ll just call everything we want to do “small” and game the system.
A: That’s entirely up to you – feel free to shoot yourselves in the foot any time you like.
Our goal here is to get something in place that looks like it will work and get us stable (and credible) again.
We can debate the details as we go.

14. In a nutshell
We rebuild and retain our focus on delivering user value.
Restore our confidence so that we can tackle bigger things in future.
Time spent on fixes, achievables and features will naturally ebb and flow over time.
We aim to strike a balance between fixes, work championed by the team and work
“the business” needs.
We work like this until it doesn’t work or we find something better!

15. What it (roughly) looks likeTeameffort
Time (sprints/months)
Analysis
Features
Achievables
Fixes

16. 1 – “Fixes” - Support issues & customer bugs
Driven by: Customer support + Jira data
Size: Variable (but mostly small to medium)
Team: ~2 team members (on a staggered 2-week rotation)
Analysis needed: Usually technical – replicate issue, try fix, validate with customer(s).
Priority: On-demand
2 – “Achievables” – tactical wins
Driven by: Team with occasional review from product management.
Size: Variable (but mostly small to medium)
Team: 1-3 team members per item. (~1 item active at a time).
Analysis needed: Limited (spike, approach review sanity check with customer(s), check size, edge cases
concerns and impact).
Priority: Negotiated relative to support and feature work
3 – “Features” – strategic changes, additions and improvements
Driven by: Product management
Size: Variable (but mostly small to medium – we’ve lost our appetite for really big stuff but are hoping to regain it)
Team: as much of the team as can sensibly work on it at a time
Analysis needed: Significant (Feature lead* and UX collaborating with product management and
customers.)
Priority: Generally higher than anything but customer escalations.
4 – “Analysis” – lead-in work to features
Driven by: Product management
Size: Variable (but mostly small to medium)
Team: Feature lead*, Product manager & UX plus whoever else can support
Priority: Occasional - Whenever queue of “ready” features has less than 2 items.
What:
Review and fix incoming support issues
Work on a continuous queue from Jira (e.g. the top 5 most reported bugs in the last 3 months plus the
top 5 newest/most recently hit).
What:
Team-led improvements to the product that have a direct impact on the user
These may be cosmetic, functional, reliability, performance
Backlog built up and prioritised by the team
Do small-medium things and do them well, not do big stuff badly
Prioritise teamwork over individual work
The team agrees what we’ll do
Allow us to deliver a stream of frequent releases with customer value
Maintain a pipeline of the “top 2” things the team want to deliver for our users
Ship frequently
What:
Improvements of varying size that take us toward product, division and company goals
Led by customer requests, market demand and product management expertise.
Require functional, technical and user analysis to translate from request -> need/goal/problem -> options
-> story backlog
Will typically build their own backlog of stories
What:
Taking incoming requests/ideas and translating to user-defined problems, goals and needs
Taking user-facing problems and identifying alternative options, solutions
Validating and scoping options/solutions
Understand impact across support, sales, marketing etc.
Preparing a team-facing backlog based on best selected option
If there’s no “feature” work to do, we’ll divide our efforts between analysis, fixes and achievables.
Support/Achievables work may slow down to deliver features depending on what priorities we agree and who can contribute to what.
Analysis will be performed when a new item needs to fill the queue of “ready” features at the cost of other work.
Work for SoC will reach the team via 4 streams. We want to ensure each stream progresses whilst also adjusting to priorities.
All work will be defined in terms of user value unless we all agree an item of work is genuinely more important or valuable to us.
*We’ll agree a “feature lead” person and review what their role entails for each significant piece of work until we have a better understanding of how to do this.

17. How will we know if things have improved?
Review previously reported issues that this was meant to help
Review balance of work and how we’re delivering
Review what’s working well and what’s not
at:
• 1 sprint (19th Feb)
• 1, 2 and 3 months. (~5th March, April and May)
• When the first, second and third “achievables” are shipped
• When the first and second analysis cycles have finished
• When we start the first feature
• 1, 2 and 4 weeks after starting the first feature
• When we finish the first feature.