I was thinking of starting this blog with a rambling story about what I do and a potted history of how I came to be doing what I do.
But then I read an article this morning that gave me a better idea. It is this article on the origins and purpose of user stories.
I like to think I’ve been agile (or at least trying) for just three years now but in that time I have become passionate about them. Not dogmatic, just passionate. That article is full of useful information and insightful opinion and it puts some interesting context behind the reason we use user stories so ubiquitously.
But, in my experience, it is all too easy for us to take the principles of simplicity and deferring of decisions too far (see my comments after reading the article). Planning is, as we all know, essential. And while we need not – indeed should not – generate highly detailed plans, we do need to understand the size (or as a French colleague calls it the “weight”) of each story sufficiently to estimate the time it will take to deliver it.
But some requirements are complicated, have pre-requites and need preparation time before a team can move the card into the “In progress” column of the story board.
The principles discussed in the article mentioned are not wrong. Far from it. But they need to be considered carefully. When do we turn a simple three-word requirement into something we know enough about to be able to estimate? When do the usability tests take place to shape the basic design and flow of a web site so that we avoid wasteful re-work?
The answer, I believe, lies in rigorous prioritisation, recognising the need for story preparation, utilising Kanban to monitor the flow of work through the pipeline, and in spending enough time up front to determine the breadth of the projects scope sufficiently to estimate the total effort.
I know of a project in which too little initial planning was done. After the first release was delayed six months – yes, six months! – the cost was re-estimated at four times the original figure. That, dear readers, is just irresponsible, and clearly demonstrates that, to be credible, agilists need to plan. Carefully.
More on the topic of planning in a future post about agile methods.