On 28th February, GOV.UK released a second beta - INSIDE GOVERNMENT.
So, six weeks later, what have we learned? From the benefits of ‘storytime’ to the real value of precocious developers, Pete Herlihy outlines some of the things the team learned delivering this release.
On April 11th, we completed the six week beta period of the INSIDE GOVERNMENT section of GOV.UK. Although it’s by no means a complete product, it is still an important step in the GOV.UK journey. It is the culmination of five months of effort between GDS, @freerange and many others from inside and outside government. I want to share a few of the most important things that we learned from delivering INSIDE GOVERNMENT, based not on what we actually delivered, but how we did it.
I think we learn more from the mistakes we make than the things we get right, so I learned a lot of things on this project! If you’re interested in finding out more about the way we work, Jamie Arnold has blogged about this in the past.
1 - If it’s hard to write a user story, it’s probably not as important as you think
At GDS, we don’t write monolithic requirement lists. Instead our approach is to focus on user needs, and user stories are the best way to achieve this. That means projects are built on a set of prioritised user stories which are typically expressed in the same format:
“As a <user>, I want to <see/do this>, so that <I can do that>”.
If we struggled to come up with the ‘so that <I can do that>’ part of the story, it was typically because we had assumed a need or it was overly prescriptive of the solution. On many projects, writing the ‘so that <I can do that>’ part is seen as a chore and skipped, which is a really bad idea. It’s the definition of value, so without it, it is difficult to know when you have delivered the story. Right at the outset of the project, we sat down as a team (actually, we probably stood up) and discussed how the stories should be written. This was really useful as this shared understanding made sure we weren’t limiting our options for the solution.
I don’t know a single developer who would prefer to be given tasks to complete over problems to solve.
2 - If it's important you will remember it
When running a sprint backlog, it’s a huge temptation to move everything that you don’t want to focus on at that time into an icebox (a ‘holding area’ for stories that you don’t want to prioritise or work on just yet). Stories that need further input are no longer the next priority, and seeds of ideas that haven’t even been written into stories yet can easily find themselves moving to the icebox.
At one point, our icebox topped fifty stories so I decided to delete the whole thing. It had become a liability to the backlog and had to go. The mantra we had in the team was ‘if it’s important you will remember it’. Living by this mantra was actually quite liberating!
3 - Investing time preparing stories before sprint planning paid big dividends
We were constantly reviewing the upcoming backlog stories as we went through a sprint. But a few weeks into the project, when our sprint planning started to take far too long, we decided to have a separate session to go over the stories each week, ahead of the sprint planning session. The product owner, delivery manager and a developer (on rotation) met and ensured that every story was well written, prioritised and importantly, that the value of the story was clear.
It wasn’t uncommon for stories to be ‘iceboxed’, or even dropped completely if we weren’t convinced of their value or we weren’t able to turn them into an effective story.
This meant that when the backlog was discussed in sprint planning, it was always well organised and focused, which led to snappier and more effective planning sessions.
I recently noted this practice actually has a name - ‘backlog grooming’, although we just called it ‘storytime’.
4 - Avoid the temptation to make the newest story the most important
This is something I was definitely guilty of. Often new stories emerged and promptly entered the priority charts at number one, not because they were the next most important thing, but with hindsight, they were the most salient.
It’s an easy mistake to make, indeed, probably human nature, but there is merit in challenging yourself if you ever find a new story slotting in atop the list. Our story grooming sessions were a really good way of challenging this behaviour.
Having a precocious development team, who weren’t averse to raising eyebrows and using the word ‘seriously?’ was a great way to help us step back and rationalise the real priority of new things.
5 - Make sure you can tell when your objectives are met
I’m used to having project objectives to deliver against, but rarely are they truly measurable. It was an incredibly useful tool on INSIDE GOVERNMENT to have these objectives clearly defined, understood and crucially, on display on our walls. It is a bit more effort to capture measurable objectives, because you need to think about how you will actually make those measurements but the return is well worth the investment.
One of our objectives for the beta was to deliver a publishing platform that met 80% of the shared publishing needs of the departments that were involved. Once we knew that we had achieved this, we were able to focus on enhancing existing features rather than being distracted by adding new functionality.
6 - Running our project in the open wasn’t a scary thing
I’ve never run a project as open as INSIDE GOVERNMENT before. We started the project deploying all of our code to a public github account, so there was already significant transparency about what direction we were heading in. However, we also decided to open up our sprint backlog so that people could see exactly what were were doing on a sprint by sprint and even a story by story basis.
I’d love to claim that we pre-planned this out of a great desire to share and be open, and ultimately we did do it for these reasons. However, the trigger was something that many others will have faced - the expiration of the free period on our backlog management tool (Pivotal Tracker).
I’m really glad we did this, but developing in the open like this meant we had to avoid sensitive details like user credentials or passwords being contained within stories and bugs. Also, as a result of @pivotaltracker tweeting that we’d gone ‘public’, we received numerous requests from members of the public to be added as contributors to the Pivotal account!
This is by no means an exhaustive list. I always find reading about how others work and what they learn in doing so, as interesting as what it is they’re building. I’m looking forward to a lot more learning (and sharing) as we move towards the launch of INSIDE GOVERNMENT.
11 comments
Comment by A quick tour of Inside Government | Government Digital Service posted on
[...] Delivering Inside Government [...]
Comment by How Community For Learning develops its platform | Community for learning posted on
[...] user stories from a real-life project and how to properly word and implement them can be found here This is all part of a process called BDD – Behavior Driven Design. If you’d like to learn more [...]
Comment by GOV.US – the cousins catching up :) | Digital by Default posted on
[...] be more ‘shareable’ in many ways than the direction GDS went in (though of course the InsideGov platform might yet become a package reusable by other teams – it just isn’t yet and I [...]
Comment by Government’s Crowning Glory — I.CO.UK posted on
[...] have blogged about the lessons learnt (a bit technical but worth a [...]
Comment by Andrew Lamb posted on
Pete, fascinating and inspiring to see the changes in transparency and openness. Are any others (i.e. departments/NDPB) following suit?
Comment by Peter Herlihy (@yahoo_pete) posted on
Hey Andrew,
I don't know of much proactive openness of this type in central government, YET, but things are definitely moving that way. I have seen some stuff in local government (e.g. http://shropshire.gov.uk/projectwip/about/) and Scottish government (http://directscot.wordpress.com/).
There are lots of good things going on, perhaps just not as much sharing....
Comment by Jamie Andrews (@jamieandrews) posted on
This is a really great post, and seeing how you do it is inspiring for people like me trying to keep discipline in our product development and get the right balance between being 'human' and having the right agile processes in place.
I have one question: in your post you talk about the need to be disciplined in writing stories in the full "As a user..." story, but in your PT project there are very few (any?) stories written like this. Can you explain where you document the full stories, and how you split them into the stories we see on PT?
Thanks!
Comment by Peter Herlihy posted on
Thanks Jamie,
We didn't care too much about the exact wording of the stories, as long as they defined the user, the need and the outcome of having that need met (the value).
Also, make sure you expand to view the detail of the story, as the default view on Pivotal Tracker is just the story 'title'. We typically included the story elements in the description, not the title. This was easier to scan the backlog this way.
You'll also see loads more examples if you look over the history of completed sprints (expand the 'done' column too see these).
What you will also see are a bunch bugs and chores that aren't compiled as user stories.
Where we haven't done stories as well as we might, and an area I still find challenging, is writing a story for a visual design elements. It is sometimes difficult to write these from the users perspective - aside from 'not wanting the page to hurt my eyes' or be more 'interesting to look at'. So I think I need to get better at defining need in this area.
Thanks again for the comments, hope this is useful in your work.
Pete
Comment by Jamie Andrews (@jamieandrews) posted on
Thanks Pete, that's really helpful (should've just expanded the stories, sorry!). This is my favourite:
As a citizen browsing the Whitehall beta,
I want policy areas which have no documents associated to them to tell me where I should be looking to see the best examples of policy content,
So I can see the intended model for publishing policy information in the future single domain for government
This could really change the way that citizens interact with policy, and it makes me happy.
Now to go into Loco2's PT and inject some discipline to our story-writing!
Jamie
Comment by edent posted on
I wonder... as the project begins to go live, would you consider having a "user generated" backlog? I know that Android and Twitter run public bug / suggestion lists which attract a great deal of attention.
I've helped run public product feedback sessions which can be really useful in understanding what a "normal" user wants. Public bug trackers are - necessarily - embarrassing but can also be a great motivator, especially if you can see how many people report being impacted by an issue.
Of course, you'd probably have your work cut out for you filtering stories like "As a user I want Jeremy Clarkson to be PM"....
Comment by Peter Herlihy (@yahoo_pete) posted on
Hey, thanks for that. In a way, we already do have a user generated backlog, although not quite as directly as you're suggesting. We have a large volume of feedback and suggestions that we collected during the beta period, from "normal" users, plus we have undertaken a bit of user testing - all of which, is used to create the stories in our backlog.
We intend to continue collecting feedback and requirements from users in these and other ways, so I think it's fair to say we are running a user generated backlog!