The Blog

Only with boarding pass

published July 15, 2010

Um… what? That was  my reaction to text which was displayed on Lufthansa’s check-in monitors at Helsinki-Vantaa airport. “Only with boarding pass” was clearly visible, but since I had not seen such instruction before, I could not tell what I was suppose to do. Shouldn’t I get the boarding pass from a check-in desk I was queuing to? There was pretty long line and thought of missing our flight crossed my mind… Luckily, gentleman behind us told that we were supposed to get boarding passes from self service kiosk and to use those at baggage drop. I felt like solving Leisure Suit Larry all over again.

• “use check-in kiosk”
• “give boarding pass”

The problem was that we definitely were not only ones that did not understand what to do. Most of the people just went directly to baggage drop desk without first printing boarding passes which slowed down the check-in process. Afterwards everything was pretty clear and “Only with boarding pass” made perfectly sense, why was it so hard?

First of all, most people did not have a script (internal instructions how to act) for this kind of event and therefore were clueless. Second thing that was wrong is that Lufthansa assumed that passengers knew more than they actually did. This is very common in IT also. Developers might assume that business people know “Strategy” design pattern or understand difference between Ant and Maven and communicate accordingly. Business side will use business acronyms that developers have no idea. Often people have a tendency to assume that their audience knows more about the subject than it actually does. This can lead to misunderstanding when neither side will not have courage to say “um… what, you lost me there”. This is especially a problem with younger people, that might just nod like they know what to do, but have no idea what should be done. (I remember doing this in my first job).

In Lufthansa’s case simple instruction like:

First do manual check-in at kiosk and then drop your baggage here. We do this to speed up our check-in process. There will be help available for you at the kiosk.

would have achieved what they were aiming for. To sum it up:

• Do not assume that your audience has same knowledge on a subject as you do
• Have courage to say it when you do not understand something

Samuli @ 22:10 (No Comments)

tags: Social psychology

Trackback URL

Managing Product Backlog

published July 2, 2010

A good product backlog is essential for sound agile development. However, there could be more information about backlogs available and best practices for managing it. A basic explanation can be found almost anywhere.

What follows are my personal findings about Product Backlogs in Finnish culture. I believe that role of Product Owner will differ between cultures and what works in e.g. feminine (Finnish) culture is not necessary a valid way to work in a masculine culture (e.g. Japan). See more here.

Who writes it?
Scrum Alliances’ website says that Product Owner “defines the features of the product or desired outcomes of the project” and “Prioritize features/outcomes according to market value”. In reality there are often multiple persons writing the backlog. Product Owner will usually write most of the backlog, but it might be that he or she simply does not know all aspects of themes well enough to write stories about them. So, product owner can delegate some writing to other business-aware people, and once written, prioritize stories together with the writer while making final decisions whether task will get made or not. Other items are best written by the team, such as highly technical stuff that will have to be made.

Where to store it?
I have tried Jira, Confluence and Excel. For me, Excel has been the best of three. Items are easiest to edit in excel and you will be able to draw charts directly to backlog. Other tools have been in my opinion harder to use.

Format
I Recommend writing items in a user story format “As a [role] I want to do [action] in order to [goal]“. Last “in order…” clause is sometimes present, sometimes not.

• As a blog writer I want to write a new blog post
• As a blog writer I want to edit published post in order to fix my spelling
• As a reader I want to submit a comment
• As a reader I want to delete a comment that I end up regretting.

In addition to story text, we have added fields:

• Priority number for story (we have often given the most important item value 1000)
• Acceptance criteria (list of things that story must or must not do)
• Time estimate
• Comment field (so that people can add temporary TODO comments)

Some backlogs also use an id number for a story, but since there should not be two stories with same priority, I have left id out and used the priority as id. It has worked so far.

Estimating user stories
The team will estimate the user stories. I have used “ideal working days” and storypoints which are just numbers showing relative size of stories.  There are some benefits using Story Points, since people are better estimating relative than absolute sizes, but ideal working days have also worked out just fine for me. Sometimes we use planning poker cards, sometimes not. Main thing to avoid is groupthink.

When do we estimate?
We usually do 30-60 minutes at a time. We have also tried to estimate 2 stories every morning after daily scrum, which also worked pretty well. Set time aside from every sprint and do estimation in small bits.

Attributes of a good story
Stories should be independent, negotiable, valuable to users of customers, estimatable, small, and testable (User Stories Applied).

Are all work tasks written into the backlog?
No. We also do other things in a sprint that does not fit neatly in to the backlog, such as:

• Backlog grooming
• Helping customer with technical stuff
• Test and production environment deployments (although these should be automatized)
• Analyzing of bugs (not that we have these :)
• Etc.

Instead, we reserve time for these tasks in sprint planning and then fill rest of the sprint with user stories from the backlog. This way you can establish pretty constant velocity and use that information to calculate release dates.

Quality of the backlog is revealed in the sprint planning
If a product backlog is in good shape, your sprint plannings will be easier. Turned that around, long and painful sprint plannings will probably have something to do with a messy backlog.

After the sprint
Once the sprint is ready, we move finished backlog stories onto a new excel sheet called “finished stories” so that we can see our velocity later. Stories that are not finished will not be counted to velocity.

Velocity chart
After stories are moved to the “finished stories container” I feed sprint velocity to a “velocity-o-meter” (excel table) and let it draw a new velocity chart, which looks something like this:

Release rhythm
The velocity chart above is an imaginary one, but it demonstrates release rhythm that I feel is often present. Amount of new stories can drop during a release (sprint 5 in our picture) and gain new momentum after release (sprint 6 in picture). Depending on sprint length, velocity can drop for couple of sprints if sprint is a short one. Ideally, this drop would not happen but I have not managed to fully prevent it. This has very much to do with the definition of done and the quality of deployment process. In addition, some solutions just need more “field testing” than others.

Summary
There are lots of things that I have learned through experience and probably other people working with Scrum do some things differently. Main goal for me is to fit Scrum into organizational culture and work with it, not against it.

Samuli @ 13:18 (2 Comments)

tags: Scrum

Trackback URL