I recently completed work with a client that was struggling with their move to Agile practices. They were transitioning from a traditional waterfall process to an Agile process for all their IT projects and were experiencing some difficulties in writing, estimating and planning with Story Cards.
Their most obvious issue was that their Story Cards were not on cards at all, they were documents stored on their corporate Sharepoint site. By that very nature, they were able to write as much extraneous information as they could type. Remember, they were moving from a traditional waterfall process, so many of their business analysts and project managers were used to formal requirements documents. The new user stories as they called them became amalgamations of requirements, functional specifications, ideas, and anything else anyone said about the user story. Being stripped of their traditional documents the teams were morphing the Story Cards into a catch-all for the functions.Â No wonder they were having trouble with estimating and planning!
What to do?
I started with first providing training on user stories to their Business Analysts and ScrumMasters. The sessions were geared to focus on their specific issues with user story writing. Examples of good and poor Story Cards were provided, as well as hands-on experience with writing Story Cards. Real-life examples were pulled from their Sharepoint site for examination during the training sessions, and used as discussion points for reworking their existing User Stories into better formed Story Cards.
Light Bulb Effect
One of the most notable items I observed there was the impact of business analysis practices in an Agile environment. Any deficiency existing in business analysis practices or skills among the Business Analysts becomes highlighted in an Agile environment. When writing Story Cards, the Business Analyst must produce a clear and concise picture of the value of the task to the end-user. This story covers describing the setting in which the end-user would be performing the work, the Why, along with Who will perform it, and When it would be done by the end-user. I call this the Light Bulb Effect – when the spark of an insight or idea occurs to the Business Analyst and this is transferred to the development team by way of a well written Story Card.