Last night I attended a meetup group in London and enjoyed a fascinating discussion entitled “What makes a good user story?” This topic is, of course, close to my heart so I was keen to hear about the experiences of other practitioners.
We organized into four groups and discussed the key points that make a good user story before taking it in turns to post these up on the wall, using Post It Notes of course! Most of the suggestions were easily summed up with the acronym INVEST. I’m not going to reiterate it here, you can read about it through the link, but for me the most interesting ‘characteristic’ is N for negotiable.
In fact, I felt that many of the problems covered were as a result of too little focus on the N, and perhaps too much on the other, more tangible, characteristics. I say this because we kept coming back to the purpose of a user story. The following is not a direct quote but I have tried to describe it as succinctly as possible.
A user story is a unit of collaboration which the team collectively develop until they have all the information they need to implement it correctly. It’s the journey from idea to tangible units of work. A story is a life cycle and can be good for different reasons at different stages in that life cycle. An initial user story that triggers useful debate and leads to a common understanding is as good as a story that contains the I, V, E, S and T.
One issue that came up several times was the level of detail that should be included in a story. What the above statement suggests is that you keep Negotiating until you have V, E, S and T. Personally I’m not totally convinced by Independent, I understand the reasoning but I think it’s dangerously ambiguous and could make life unnecessary difficult for anyone that takes it too literally.
My favorite quote of the evening: “remember to keep stories short, Testers and Developers hate reading long texts!”