davidbgk
/
larlet-fr-david-cache

title: User stories on steroids – how Estimote uses “blog post driven development”
url: http://blog.estimote.com/post/119525082855/user-stories-on-steroids-how-estimote-uses-blog
hash_url: 380e6baf0541e260399c52759c6cdb3b

<p>Planning and defining the work of an SDK team is a special challenge in software development. Such teams don’t always have “visible” deliverables in the same way a web or app team do. The team’s work is developer-facing – by developers for developers - and much of the planning is on a deeply technical level. The smart people in the team often have strong opinions about how things should be done, and conflict can arise if we don’t understand the “why” of our work. There’s also what I call the “SDK cave” danger, where losing sight of the bigger picture can lead to a team going badly off track. I’ve regularly witnessed the scenario of an SDK team who disappear from sight to develop the next great thing, only to emerge from their SDK cave to learn that what they’ve done isn’t really what anyone wanted…</p>

<p>At Estimote, we’ve hit on a technique that helps us with these issues, and ensures we talk about “why” and “what” before diving into “how.” We call our approach “blog post driven development.”</p>

<p><img src="http://i61.tinypic.com/25pp8nm.jpg" alt="enter image description here"/></p>

<p>
In simple terms, before we write a line of code, we start each sprint planning session by outlining a blog post describing what our next release will be. The technique helps us avoid premature discussion of implementation details, instead focusing first on what impact and value we can deliver with our software, as well as making sure we really understand the problems we are trying to solve. 
Our product owner kicks off planning by suggesting a potential headline for the blog post that communicates the overall theme for the sprint. No-one likes a dull headline, so robust discussions tend to take place from the very start. If necessary, we’ll refine and iterate on this headline immediately. We can normally tell if we’ve hit on a great approach just by our reactions and energy levels. More than once we’ve turned “Boring! Nobody is going to care about that…” into “Wow! Developers will love that…” at the headline stage.</p>

<p>Then, as a team, we’ll put together a list of bullet points for the blog. Explaining our thoughts to the rest of the team out loud is a great test of our own understanding – and of the awesomeness of the feature. Just watch the faces around you. During our planning we’ll also consider how we’re going to explain our work to users – will we ship this with example code, for instance, and what will that example code do? Or should we just make it simpler so it needs less explanation? Will the blog post need illustrations? What does the documentation need to cover? This discussion helps all team members develop product skills, and ensures we think about the wider context of what we are doing. What does this mean for our company? What impact will this have on our developer community? Note that this isn’t about producing vague marketing material – this is about a detailed blog post that describes real, working features.</p>

<p>Planning is “done” when each and every team member understands enough to be able to write a blog post themselves, and we have a skeleton post that we can commit to making a reality during the sprint. It’s a lean approach – we put together just enough of a plan for us to understand what we need to do, without the micro-management of anyone telling us how to do it. Right now each planning session defines a mini product launch – which is incredibly good for morale.</p>

<p><img src="http://i59.tinypic.com/2wdxbth.jpg" alt="enter image description here"/></p>

<p>We’ve adapted our Kanban board to suit this way of working – our first column is now “Blog post (a.k.a. ‘why this is awesome’)”. There’s room there for an A5-sized Post-it note with our bullet points. Lean again – just big enough to cover the essentials. The inevitable debates about implementation details are easier to resolve if we’ve all been involved in defining why this piece of work matters, and actually have the “why” visible to all. Try this test with a random development team – ask them why the tasks they are working on are important. Our technique makes sure that all of the team can answer the most important question.</p>

<p>We share the blog post outline as soon as possible with other teams in the company – early feedback is always useful. And when we actually write the blog post, we’ll often collaborate across teams, so we’re seeing the added benefit of breaking down barriers in the company, and different teams getting to know each other better (even across continents).</p>

<p>Blog post driven development is also an alternative way of approaching “definitions of done,” whilst avoiding dull checklists that don’t force you to think for yourself. “It’s not done until it ships” is a well enough axiom to (hopefully) need no further discussion – but for us, it’s not done until it’s shipped, publicly announced, documented, has examples, can be used by a new developer with ease, delights our users, and we’re getting feedback on it.</p>

<p><img src="http://i62.tinypic.com/as8q0.jpg" alt="enter image description here"/></p>

<p>We also use this technique for any refactoring or housekeeping we need to do in our SDK. The same test holds for this kind of work – if there isn’t a “wow” factor to it, maybe we should rethink. Our internal teams are the first consumers of the SDK, and if we can make an announcement that leads them to say “that makes development faster / makes it easier to test / makes life easier” then we know we are on the right track.</p>

<p>You might say “this is just like user stories.” And yes, the aim is similar – focus on delivering user value. But blog post driven development is like user stories on steroids – our discussions of future announcements help us consider so many different angles and approaches. All too often teams think they are benefitting from user stories by prefixing “As a user I can…” to any old task, whilst forgetting to ask “why does this matter?”.  Our starting point is to make sure every member of the team understands “why.” It’s a simple tweak to the process, but the alignment this provides us with is one of the main reasons we’re moving faster and releasing more often than ever before.</p>