blog.fossmo.net

Have you ever experienced how pacified you can feel when a co-worker takes control over your keyboard and mouse? It feels like he or she is intruding into your personal sphere. You might have asked for help, but not to be invaded. It's strange to think of how much "power" the person controlling the mouse and keyboard has. If the person holding the keyboard and mouse isn't aware of the "power" he or she got, and don't bother to include the other person, it's likely the person falls into a apathetic state just watching the screen, and not focusing on how to solve the problem.

When doing a sprint planning you should avoid using a electronic storyboard. My experience is that you end up with one person, probably the scrum master, running the whole show. The other team members will probably sit pacified looking at the screen. Doing nothing, or in best case trying to participate but not being able.

You should rather use a story board hanging on the wall in your office. Perhaps a whiteboard or maybe a board made of gray paper. And Post it’s, of course. This way everyone can participate in the process of adding tasks (and user stories). This promotes cooperation and builds team spirit. Everyone can have hands on experience with the process. It builds understanding for the problem being solved. It lets the team work more in parallel. While one team member is finishing writing one task (or user story), another member can start with the next task (or user story). I'm not saying that an electronic story board can't be used, but you should have very good arguments for using it. It's to pacifying!
If you disagree, remember one of the statements in the agile manifesto; "Individuals and interactions over processes and tools".
What is your experience with electronic story boards?

Tags: scrum

In many projects I have been working on, I often have seen that it can be problematic to get the product owner to create users stories with business value. The product owner understands what he or she wants, but forgets to focus on what is important to the business. If you run into this in a project, you should tell the  product owner that he or she never should create a user story that have no business value.

If the customer find it difficult to get the userstories down on paper, a pattern like the one below can helpe the product owner (or also the team) to get started: 

As a ROLE I want to ACTION so that BUSINESS VALUE (IS MEET)

Every user that interacts with the system should be put into a ROLE. Roles can be a user, a administrator, a report viewer and so on.

The ACTION is what the role is doing to the system.

The BUSINESS VALUE shoud be something that gives value to the business (or at least value to something using the system).

Here is a example of a user story that contains a business value:
As a user I want to log in with a password and a username so I can buy a Ipod.

And a example of a user story that probably doesn't contain any business value:
As a user I want to click a button so that the background color changes to green.

The last example does not give any business value to the customer and shoud never be added to the backlog in the first place. If the product owner later wants to add this story, it's ok, but it should be proritized last in the sprint.

Next time you are doing sprint plannig you should try to follow this simple rules, and I think you will end up with less features to be done in the sprint and you also will give the customer a application full of business value.

Tags: scrum