I will be presenting at the next Melbourne Patterns Group on LISP. It will be a quick and simple introduction to the language and why I think you should use it.
There will be two special guests to support my presentation !!
The date and time is September 3rd at 6:30pm and the address can be found at the web site linked above.
I hope to see you there.
Creating a Product from a list of System Attributes is not as effective as creating one from a list of User Goals, and while useful, it is not going to lead to a market leading product. Here’s why:
The System Attributes approach is why we have MP3 players like the Creative iRiver, while the User Goals approach is how we get the Apple iPod. We both know which MP3 player dominates the market by 90%, the Apple iPod, and yet the iRiver has more features (attributes).
For example, here is a list of System Attributes:
1. The product shall have a gas engine.
2. The product shall have four wheels.
2.1. The product shall have a rubber tire mounted to each wheel.
3. The product shall have a steering wheel.
4. The product shall have a steel body.
What does the System do for the User ?
What attribute should be done first ?
Here is an example of a list of User Goals that the System should support:
1. As a user, I want to mow my lawn quickly and easily.
2. As a user, I want to be comfortable while mowing my lawn.
Both of the examples above describe a Lawn Mower, but only the User Goals approach removes the ambiguity necessary to creatively and efficiently deliver what the User actually wants and will pay for.
I support / promote a move from the System Attribute approach to the User Goals approach because:
1. We can deliver each User Goal incrementally and get a ROI sooner.
2. The resulting Product is what the User wants and will use, because this was the driver.
3. We can easily go from User Goals to a list of System Attributes, but not the reverse.
4. The resulting Product will be more cohesive.
*The example attributes above are taken from the presentation, “User Stories Applied” by Mike Cohn.
In this post about Exploring Requirements I spoke about the need to get good requirements, even if using an Agile process, but how can we capture these requirements as good User Stories?
Writing good User Stories is a skill that takes practice, and I think that removing ambiguity and conveying the problem being solved are keys to good stories. There is also the acronym INVEST to guide you well. This acronym is covered in this blog post and in this blog post, so I won’t regurgitate it here, but please take some time to read them.
There are many schools of thought about how big or small a User Story should be but my preference is to make them fit comfortably within the teams iteration. So if the Story can’t be done within an iteration it is probably an epic story that needs to be broken down into smaller stories. Smaller stories are easier to complete and this helps the team maintain a positive rythmn and feeling of progress. However, a Story should deliver something of business value to the customer, something they can use, which I think is a key to just how small a Story can be.
There are also many opinions on what details a Story should contain and to what level the details should go. For me, a Story can be just the title and one or more tests. It must have a test.
If we take the requirements from the Exploring Requirements post we can easily convert them into User Stories, with the requirement becoming the title of the story. For example:
What we can also see from this set of Stories is that Story #2 is probably an Epic, since the range of things that can make a BABY uncomfortable may be rather large. In this case I would split the Story into smaller Stories and capture the linkage to the Umbrella/Parent/Epic Story in the title of the new Story. For example:
You may think that the Stories #2 and #3 don’t need to be separate. I make this judgement by checking to see if there is a different priority for each to the Customer. For example, if being too cold is worse than being too hot then story #3 would have a higher priority, and therefore it makes sense to have it separate so it can be scheduled and delivered individually. Where the priority is the same then it comes back to the ability for the Story to be delivered in a single iteration and separating it where this can’t be achieved.
Often I am asked where the solution details go and the answer is, not in the Story, but in the code and or comments or attachments to the Story. The Story should stand alone from any particular implementation.
At the end if the day the best User Story detail and size is what works best in your Team and for your Customer.
We have a new Customer at home and they have three requirements:
What I hope you will notice from the above requirements is that they are stated as close to a problem as possible, and the level of ambiguity is rather low. While this example may seem trivial it is surprising how many requirements I see that are stated in terms of a solution, that contain attributes of a solution or are peppered with ambiguity. I have found it hard to get a Customer to see these problems and amend the requirements accordingly; I think it’s much harder than looking after my new Customer, and that’s all consuming and *very* hard.
Agile encourages small feedback cycles and on my current work project this cycle is two weeks, and while this is the timeframe in which the Customer will confirm our course to be correct or not, we can do a lot more to ensure the possibility of moving in the correct direction by spending more time on the requirements themselves. Time spent removing ambiguity and ensuring the wording makes clear what the problem being solved is.
Studies have shown that the costs of fixing errors in the production phase created by false assumptions and ambiguity in the requirements phase are a ratio of some 40 - 1000 times. So economics suggest that more time should be spent on the requirements, and although Agile may mitigate some of these risks the risks remain making it economically prudent to have good requirements.
As a developer I want to give the Customer what they want, and by ensuring they convey the problem they are trying to solve, I am more likely to give them a solution to the problem, even where ambiguity exists. Where a requirement states all or part of a solution the chances are you wont have solved the Customers problem, since you don’t know what it is, and the Customer wont be happy because the problem still exists. A requirement that states a solution can sometimes remove the possibility of options being presented to the Customer, but this depends on the team culture.
Ambiguity exists when two people can read the same requirement and make different assumptions, for example, comparative words like “small” or “inexpensive” lead to ambiguity.
There are a lot of techniques for refining requirements, driving out ambiguity and focusing the requirements to convey the problem and the best collection of these techniques I have found is in the book “Exploring Requirements, Quality Before Design” by Donald C. Gause & Gerald M. Weinberg. However, if time to read the book is an issue, just ask “why?” at least five times on each requirement and “what problem does this solve?”. I typically find this approach uncovers a mass of things that need to be covered.
Update:
Some people have asked me about how requirements can be ambiguous and I thought an example from the book would be ideal. In keeping with things that appeal to my new Customer, I have chosen the example in the book where the authors take a familiar nursery ryme and apply a process of emphasizing each of the words in the line, one by one, and then in combinations to identify ambiguity. They uncover 32 different meanings of just the first line of the familiar poem, that could be 32 different solutions all of which may not be right for the Customer. The poem is:
Mary had a little lamb.
its fleece was white as snow.
And everywhere that Mary went,
The lamb was sure to go.
Here are some of the different meanings uncovered in just the first line of the poem, but please get the book to see the full set which really drives home this technique.
Mary had a little lamb.
(It was Mary’s lamb, not Tom’s, Dick’s or Harry’s.)
Mary had a little lamb.
(She no longer has the lamb)
Mary had a little lamb.
(She had only one lamb, not several.)
Mary had a little lamb.
(It really was surprisingly small.)
Mary had a little lamb.
(She didn’t have a dog, cat, cow, goat, or parakeet.)
Mary had a little lamb.
(John still has his little lamb.)
Mary had a little lamb.
(As contrastred with Pallas, who still has four large turtles.)
My personal favourite is what happens when you apply different dictionary meanings to the words, like ‘had’, for example:
Mary had a little lamb. So what did she have for desert ?
Have you ever wanted to hear ‘Yes’ rather than ‘No’ to a question you have asked ? I’m guessing you just said ‘Yes’, which shows me that reading the book “The Science Of Influence, How to Get Anyone to Say “YES” in 8 Minutes or Less“, by Kevin Hogan was worth reading, and it probably is for you too.
The book helps you to communicate more effectively by helping you understand the many complexities of communicating. Complexities like verbal, non-verbal, time, place, tone, pace and peoples behavioral patterns are all taken into account and explained. The book also covers what to do when someone has said ‘No’ before or the equally disappointing ‘Ill think about it’.
I read this book because I want to be a more effective communicator in my role as a change agent, introducing Agile development practices in new organizations, but I could use these techniques everyday, wherever I want to get a ‘Yes’. However, I believe the techniques not assist me in winning and argument with my wife, not even after reading Chapter 10.
he book was an easy read for me, with an appealing size type and what felt like a logical sequence of chapters. Here is the Table Of Contents:
The book has key questions and call outs to throughout the book which serve to drive home a point and I found myself making a list for quick reference later. Here are a few as an example:
Nothing persuades like credibility in people’s decision-making process.
When faced with too many choices, most people can become paralyzed and do nothing at all.
The brain makes stuff up out of thin air to fill in the blank spots.
What people say and think they will do bears little relationship to their actual actions.
How we dress in large part determines how much people will trust and like us.