You’ve all heard the words – “we should….” that open ended statement before those perfectly harvested requirements are thrown out the window and a new set discovered – right? I certainly have. Once upon a time I would call this kind of talk + resulting activity “rabbit holes” or “cul de sac’s” – that was my pre-agile life, now we embrace these statements and turn them into Research Stories for our backlog.
What on earth are Research Stories
For OptimalBI, research stories provide sprint team members with a tightly defined time boxed window and resources to essentially investigate a concept, or technology, or method or “thing”. If we collectively agree with the product owner that the research has legs it can follow one of three paths:
- a second small research story;
- a new story in the backlog as a Proof of Concept (POC) Epic;
- a new story in the backlog – as a story to be delivered.
Research stories are an invaluable resource, they ensure we explore the options or opportunities presented in a controlled way – the control is on time and outcome – and in a very collaborative accountable way. They encourage innovation and challenging the status quo without exposing us to outrageous variations or delays. We apply the same principles to training undertaken, training is by it’s nature a form of research, with an investment in time and cost. So to prevent that investment languishing with the individual who attended or consumed that training – as often happened in our pre-agile lives – training always has follow-on activities and stories to deliver outcomes.
Why they work
The Acceptance Criteria for Research Stories all have 4 compulsory elements, Done-Done cannot be achieved without these 4 dimensions met – in addition to anything specific for the research itself. All self explanatory but I have added a short definition:
- Collaborative – while research stories can be led by one team member a peer needs to be involved
- Time boxed – initial sizing box of 2-4 hours, can be scoped to 8 hours, larger research than this usually should be multiple stories and broken down, or moved into a POC
- Outcome focused – like everything we do research is focused on the outcome to be achieved, clear Acceptance Criteria to clarify
- Findings must be shared – usually a blog, or series of blogs, to share findings in “how-to” form, or opinion piece if the research didn’t get legs
You can try this too
If, like us, you have headed down the Agile path or are watching the method with interest, you can read Shane and Geoff’s blogs full of insight, tips and tricks based on our own experiences and you can apply the concept of Research Stories into any other process. The benefit of clear definition, time boxed and collaborative research could be added to any Waterfall project plan as a task or any work management system as an activity. Give it a go, you might be pleasantly surprised. Vic.
Thanks for the wonderful Scott Adams for yet again providing this inspirational insight via Dilberts life www.dilbert.com