Writing User Stories for Your Strategy

Writing User Stories for Your Strategy

What makes a good strategy document?

I’m sure it is a common phenomenon: a strategy gets written and no-one in the team ever looks at it again. There are many possible reasons why this might happen. For one, the plan could be totally unrealistic (you’ll find out in time whether that is the case for your plan).

However, the failure mode for strategies that this post seeks to abolish is: Strategy document does not directly address the questions of the team. Maybe you, as the team manager, get something useful from it but it can be hard to get the team to identify with the strategy, or see why they should ever use it if you don’t think very hard at the outset what each of them would want to know.

Our problem was that a lot of the templates were very cumbersome - too cumbersome for our size of team to digest and implement. We needed a template which was lightweight and would enable us to make decisions based on what the team had agreed were priorities.

My philosophy is that a strategy should be a useful document for the whole team, not just the team lead. This means there probably is no such thing a one-size-fits-all strategy template.

In this post, I have shared our list of ingredients for both a strategy and an implementation plan as the two are closely related. Hopefully they are useful to others, and I would love to hear if there is anything you think we have missed!

A confession

Our first strategy at School of Data was more like a wishlist of all of the things we would like to do. This was great because it meant that we dreamt big and did some things which were amazing - but it didn’t help us prioritise, work out who should be responsible for making decisions or work out how to resource requirements.

A potential solution

We brainstormed very concrete use cases, or user stories with ourselves as the main users. e.g.

As the team lead I need to know which roles we need for a project of the ambition of ours so that I can plan my hiring and resourcing accordingly.

As the fundraising lead I need to know what my fundraising targets are so that I can know when to stop raising money and muck in with the implementation .

Strategy vs implementation plan

Working with my School of Data colleague Milena Marin - we came up with a list of what our team required from a strategy vs an implementation plan.

Some definitions

“What is the difference between a strategy and an implementation plan?”, I hear you ask…

Well, for us:

  • The strategy was the aspirational document - outlining everything we would wish to do on our quest to change the world

and

  • The implementation plan was where parts of the strategy moved when they met all of the conditions to be given the ‘go’ and we needed to actually deliver them!

Strategy

Meta requirements

A strategy should:

  • Have a clear owner (myself in this case) - who maintains the strategy and checks the team is sticking by it. The owner also makes changes when required - but any reasons for changing should be made very clear to the team.
  • Be version controlled - for me, it is important to be able to compare past versions of a strategy to help the team and myself remember what we did in the past and how our thinking has evolved.
  • Specify times and conditions for review - it is important that the team knows how long the plan will be relevant for, and how they can act to change it if necessary. This means both setting a time for review in advance and also specifying a set of conditions which may also allow people to convene a re-thinking session.

Content requirements

Below are what we felt to be necessary ingredients for the School of Data strategy

  • Mission statement & theory of change - to answer the question: “Why are we doing this again?”. (Aside: I really like this theory of change template from the DIY toolkit.)
  • Activity types - e.g. are we doing online and offline activities?
  • Thematic focus areas - important to see for School of Data whether we were going to focus on particular topic areas.
  • Stakeholders & partners - who are they? what type of partner are they?
  • Prioritisation of activities - so that the team can know what we are going to aim to launch first and what could come later.
  • Geographic priorities - are there any considerations on where we should and should not work?
  • Resourcing needs & fundraising plan - how much resource do we need to acheive the scope of our ambition?

Structuring the strategy

The School of Data strategy is currently itemised. For each point, we have a goal (sometimes called a headline), rationale, methods and success criteria. Here’s an example:

  • GOAL: Improve and expand teaching methods
    • RATIONALE: School of Data training has gained a reputation for effective capacity-building through hands-on, participatory methodologies. Formalising, documenting and teaching the teaching methodologies as well as the actual skills would enable us to empower more data trainers. As fellows are currently in training to build their teaching skills, it would be logical to prioritise them.
    • METHODS:
      • Create annual Summer School for fellows to learn facilitation skills in a more structured environment, and network with other data practitioners;
      • (Add more here…)
    • SUCCESS CRITERIA
      • Fellows attend summer camp and use some of the teaching methods in their own training. Fellows receive excellent testimonials about their teaching.
      • (Add more here…)

Implementation plan

As above - here are the elements we found important to make sure are covered in the implementation plan:

Meta requirements

All the meta points from the strategy also apply for the implementation plan. However, the validity of the plan and the review cycles are likely to be shorter and the breakdown of tasks is likely to be much more granular.

One further note on roles: I, as the team lead, am the point for the strategy. Milena is responsible for the implementation plan. We both obviously back each other up, but having this split of responsibility is a sanity-check - if one thing sounds great in the abstract strategy but we can’t translate into the implementation plan, we should reconsider the strategy.

Content requirements

  • List of activities & owner - who is leading on what? what is their remit? who is ultimately accountable if a thing doesn’t happen?
  • Stakeholders - for each of the activities, who needs to be consulted and involved?
  • Resource allocation to tasks - what resources (both people and money) are actually allocated to acheive a particular aim? Implementation only begins when resources have been allocated!
  • Prioritisation - this can be more granular than in the strategy, as you will need to work out implementation details.
  • Milestones & timeline - by when do we expect to have acheived our goals?

Have we missed anything?

Please do feel free to get in touch on lucy [at] fedia [dot] net if you have any further recommendations on the above!

Further reading:

  • Forbes article on what to include in a strategic planning template. I didn’t follow this personally - as I felt like the strategy should be relatively succinct. I felt things like SWOT analysis should inform a strategy, but the strategy should be to the point.
  • Management Help Post - on a similar topic to the above. Lots of good stuff in there, but again, I felt a bit heavyweight for our requirements!

Get updates straight to your inbox!

Alternatively: