Why "As a" in User story template is important

It gets interesting if two different persona (different users) find a given feature of software contradictory. I was thinking about one today, where we worked with one group and same story could cause whole bunch of unintended activities for other groups.

In software development process people write stories in the similar manner that a filmmaker make a blueprint of a movie by constructing story board.

Each feature is captured as a "story", which defines the scope of the feature along with its acceptance criteria. The narrative should include a role, a feature and a benefit.

The template of user story: "As a [role] I want [feature] so that [benefit]" has a number of advantages. By specifying the phrase "As a" within the narrative, you know who to talk to about the feature and also reminds you of a role or persona. Someone who can benefit by using the system (until then the system just costs). By specifying the benefit, you cause the story writer to consider why they want a feature. If you can't actually spell out the benefit, then something is missing.

Having done the homework and describe the same story from different point of views can save time and re-work. It seems like a good habit to write the same feature from different group's perspective.

Here is a an Aesop fable (great for telling your kids at night time) showing two different persona (Fox and Crow) having different goals in a situation.

The Fox and the Crow

A fox was walking through the forest when he saw a crow sitting on a tree branch with a fine piece of cheese in her beak. The fox wanted the cheese and decided he would be clever enough to outwit the bird.

"What a noble and gracious bird I see in the tree!" proclaimed the fox, "What exquisite beauty! What fair plumage! If her voice is as lovely as her beauty, she would no doubt be the jewel of all birds."

The crow was so flattered by all this talk that she opened her beak and gave a cry to show the fox her voice.

"Caw! Caw!" she cried, as the cheese dropped to the ground for the fox to grab.

Why open source software works?

Open source developers, scratching their own itches. They don’t suffer from phony deadlines and decisions others make for them. They are the first class customer for what they produce and the problem "let’s check with users and where the requirement …is" simply doesn’t exist.

Bad for your brain

Multitasking is a taken for granted attitude for many managers. I recently reminded one about the cost of multi-tasking, but the answer was “you can drive while you talk…” Surely this is multitasking. But are we serious about paying attention? When it comes to that your poor brain isn’t capable of multitasking. However, multitasking is a great way of prolonging your projects.

Buy Don't Build

Now that I am working at a Start up, the concept of build vs buy is the top topic of my daily life. Here is the principle that I am following:

• Buy big things (operating systems, compilers, database engines) and build small things.

The main question is? Does a system “Upgrade your users” and not just the product? Does it enhance user’s life?

Estimate using probability curve

Programmers usually pick the earliest possible date when they are asked to estimate. Tom Demarco and Tim Lister make this observation with the probability distribution diagram. The area under the curve shows the probability from 1 to 100%. The most probable date of complete is August 9 and we are certain that 100% of the project will be complete by February 20. Tom Demarco and Lister refer to earliest possible point of completion, June 17 as the "nano-percent date". Nano date is the one that managers like and if you give them a range like this diagram it may not go well with them at all. This explains the fact that programmers estimates at Nano date and things always takes longer.

Video Specification

YouTube is a great way of learning almost anything. Why not create a similar tool for your company to deliver visual requirements to remote teams besides sending a textual specification.
Those who are remote then have a chance to watch a three minute video and get an idea as to what the topic is. However, if people who are making a 300 page of boring specification are the same who will make these videos then forget it.

What should project managers do when it comes to planning?

What should project managers do when it comes to planning? There are tones they can do to avoid wasting people’s time and bore them to death by putting fungible names on a list while playing with fake numbers.

I think there's a better way (this tool has steps), one that gets everybody just about everything they need, project managers, bosses, programmers etc. Here goes:

Step one: download Jeff Patton’s (from Thoughtworks) wonderful article on “It is all in how you slice”. You should print the article on a colored paper (forget the lousy cost savings policy – it costs more not to have it in color). Read it carefully.

Next step: Print more copies for people who might be interested or benefit from this tool.

Next step: follow the steps in the article for one of your projects. See if your team or customers will benefit from this process/tool.

Next step: visualize your exploration. Something 1 foot by 2 foot or so. Printed on cardboard. You can transfer the findings onto a spreadsheet or just take a picture and communicate.

Last step: Make this a habit and invite your best customers to help in your planning. Look into yours and other people energy level and compare it to the way planning was done before.

Send me a testimonial comment if this helps.

Welcome to feedback culture

Smart customers know that projects are done by a step by step process, not an event.
Instead of this:
Request ---> Complain
It works like this:
Request---> sample ---> ask for feedback ---> learning ---> more sample ---> accept ---> relationship

Stand ups

It seems that people have a fear of justifying their work during standups rather than focusing on what can be done.
Last week I created a big visible chart (story wall) of actions, how and when columns and stuck it to the wall for everybody to look at. This helped people to become focused and they started signing up for tasks as oppose to a push system which managers assign tasks to programmers.
We also tried to prevent people from going into detail. Initially we were showing the red card as a signal but recently adopted yawing for indicating too much into detail sign. Yawing is very contagious - start yawning couple of times when a meeting gets boring, you’ll be amazed as to how many people will get infected and start to yawn.