Darryl Booth has recently taken on the role of Client Services Manager at Decade Software, but for the last few years he has been the guiding force behind our Design Team.
The Design Team itself has also underwent change, as many designers have grown with the company and taken their knowledge of the application into other departments.
With EnvisionConnect's foundation laid and its core functionality solidifying, the remaining designers are struggling to keep up the pace of subsequent product iterations. Does this surprise you?
We have found that the bells-and-whistles of subsequent iterations—those additional coats of paint that all good applications require—are extremely time-consuming, both for the developer and the designer.
Just as one code change can break code downstream, technical choices in first iterations can often change the course of subsequent iterations, so if you think that the designer's job gets easier in subsequent iterations, you are mistaken.
Sure, by now the remaining designers have had extensive communication with the customer, and they have meticulously documented the customers every need. However, as customers use the application provided by the initial iterations, these customers have reserved—no demanded—the right to change their minds.
There are many things that can make a designer's life miserable in preparing those subsequent iterations, but the toughest is likely the time spent on communication.
Darryl came to me yesterday saying, "I'd like to boil down the details of each use case into goal statements for each item on the product backlog. I believe it will help communication between designer and developer if both are clear on the essence of what the customer expects to be delivered, even if the details have to be changed. What do you think of this idea?"
"Sure, Darryl," I said. "I'm always open to improving our processes."
Later, I met with my teams and explained the idea.
My teams hate change, so they weren't exactly jumping up and down, but they agreed to be patient. Afterall, we still have use cases for the details. This new goal statement is just a guiding spirit when the use cases are vague in areas.
At home last night, I realized I was experiencing déjà-vu.
The statements of the day sounded suspiciously like an agile development practice that our company has never experimented with—something called User Stories.
Mike Cohn is well-known in the Scrum world, but he is better known as the father of user stories. However, if there is a mother of user stories, strangely, that would have to be author Bill Wake.
Bill defined the acronym INVEST as a guide for writing stories. This guide dictates that all good user stories are...
- Independent
- Negotiable
- Valuable (to users or customers)
- Estimatable
- Small
- Testable
User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the sprint planning meeting. They are also used instead of large requirements specifications.
User Stories are defined by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.
User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.
One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.
Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning.
Another difference between stories and a requirements document is a focus on user needs. You should try to avoid details of specific technology, data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed to specifying GUI layouts.
Of course, this is all very interesting, and I have no idea whether Darryl's idea will eventually lead us into true user stories, but I am anxious to find out.
No comments:
Post a Comment