Kano Questionnaires

synoppsys: The Kano questionnaire is useful (at least on a small scale) as a supplement to the more qualitative data revealed in interviews and focus groups about features that are important to users.

I recently read about the Kano Questionnaire in Mike Cohn’s book, Agile Estimating and Planning and in another article by Cohn. It seemed like a really great way to determine quantitatively what user stories are important to our customers/users. Using Kano’s matrix, you can cross-check an individual’s response to a functional question (the feature is in the system) and to a dysfunctional question (the feature is not in the system) into one of three types of features: 1) must haves; 2) linear (the more, the better); 3) exciters and delighters (cool stuff the user doesn’t know that he wants).

In 2007, we released a web application at the college level for academic advisors to track student contacts. Now it’s being considered for release at the university level. We entered a pilot phase and just finished up focus groups with the participants. From the focus groups and various other surveys, we were able to glean an initial list of user stories. We wanted to confirm our qualitative research with hard data (as we write a proposal for funding) about what features are most important to the users.

We sent a questionnaire to pilot participants with 3 Kano-type questions. We picked three stories that emerged from focus groups that we wanted to confirm quantitatively.

Practice Sprints

synoppsys: At the beginning of December 2007, our team engaged in 2 practice sprints (in 2 week iterations) within the Scrum project management framework with mixed success.

The two mini-projects were:
1) a new home page for one of the sites we support;
2) a “spike” on Ruby as applied to another one of our applications that needs to be rewritten.

Summary of our Sprint Retrospective:

What went well?

• Introduced peer accountability.
• Kept us focused.
• Added structure to the process.
• Gave us short-term goals.
• Daily meetings provided opportunity to quickly check status.
• Good for team-building.

What didn’t go so well?

• Did not do burndown charts.
• Took on lots more than agreed-upon.
• Did not write in stories.
• Kept track of actual hours, rather than estimated hours.
• Felt bad in daily meetings if we did not accomplish anything the day before.
• Couldn’t analyze tasks (which were being tracked in Outlook).
• Spikes are uncomfortable if you’re working by yourself.

What will we do next time?

• Write in user stories.
• Estimate product backlog in story points.
• Prioritize stories.
• Estimate sprint backlog in hours.
• Do burndown charts.
• Try Sharepoint with backlogs in Excel.
• Do more research on Scrum.

Since these practice sprints, we have completed a few more sprints. Each time, we are becoming more comfortable with the approach, improving our processes and becoming more productive.

Four Must-Read Books on Agile/Scrum

synoppsys: If you are beginning to explore the principles of agile software development (Scrum in particular), start by reading these classic books on the topic.

I have learned the most about agile software development and scrum from these books. I would highly recommend them.

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle, 2001.

User Stories Applied: For Agile Software Development by Mike Cohn, 2004.

Agile Estimating and Planning by Mike Cohn, 2005.

Scrum and XP from the Trenches by Henrik Kniberg, 2007.

The best graphical representation of Scrum that I have come across is located here.

Scrum: Agile Project Management

synoppsys: Our team is experimenting with Scrum, an Agile project management approach.

Scrum is a project management framework which is aligned with principles of Agile Software Development. The key values, as outlined in the Agile Manifesto, are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Important characteristics of this approach are:

• The customer is a participating member of the development team.
• We expect changes as the project proceeds and we respond quickly and flexibly.
• We deliver features iteratively and incrementally: we start with features that have the most impact on the most people.
• We strive to produce visible deliverables (prototype, graphic design, requirements document, functioning web site, etc.) in a short period of time (2 to 4 weeks).
• We define our success in terms of working features that meet customer needs.
• We pursue the simplest, while most effective, designs.

Our team has completed 3 sprints. Future posts will detail Scrum and summarize our experiences.

Welcome Messages Must Die

Welcome to my blog!

synoppsys: Welcome messages on home pages waste our visitors’ valuable time.

I attended Jared Spool’s UIE conference in Boston a couple months ago. It was a fantastic learning experience. During Gerry McGovern’s presentation on killer web content, he told us to stop saying “welcome” on our home pages. Our visitors know where they are, and we’re wasting their valuable time and our precious chance to grab their attention with a big “Welcome!” banner. I was horrified to think that we’ve got those introductory welcome paragraphs on nearly every one of our web sites. How could I have missed something so obvious?

When you feel the need to welcome your visitors to your site just like you would if they were to arrive at your physical front door, it probably means your site is still in “brochureware” mode: your site is designed from the perspective of your organization. I have no statistics to support this, but I would guess higher education web sites are generally way behind e-commerce sites in their evolution from organization-centric to user-centric design. Think about how often you see mission statements on the home pages of non-profit organizations.

Gerry’s message is clear to me: don’t waste valuable real estate on warm and fuzzy welcome messages. Jakob Nielsen calls these introductions, “blah-blah text.” One participant in a web site redesign summed it up well: she said she had been trained over the years to NOT read the wordy stuff on the home page.