Blog

The Kano Model of Customer Satisfaction is a questionnaire-based approach and is a powerful way of visualizing product characteristics and stimulating debate between the delivery team and stakeholders.

Which feature will entice customers to purchase your product? Which feature will cause customers to upgrade? Which feature will make customers so happy that they’ll ignore or tolerate the features that they wish you would fix or remove?

Gardeners prune trees to control their growth. Sometimes the pruning is artistic, and we end up with shrubs shaped like animals or interesting abstract shapes. Much of the time the pruning is designed to build a balanced tree that yields high quality fruit. The process isn’t about “cutting” – it is about “shaping.” Use this metaphor to help create the product your customers desire.

An excellent method for prioritization is Relative Weighting, which Karl Weigers introduced in 1999. This method not only provides a mechanism for prioritizing requirements based on user input and feedback but also includes the expert judgment of the team. Like other prioritization techniques, Relative Weighting allows the Product Owner to better gauge which features to implement and in what priority order.

One of the most essential Scrum meetings is the daily scrum, also known as the daily standup. It is intended as a quick meeting to synchronize the efforts of the team members to ensure that every team member is aware of how the team as a whole is tracking towards its sprint goal. This post discusses 4 ways you can ensure that your daily scrums are productive.

The job of ScrumMaster is real. It can have a big impact on costs saving the company money. But what does a ScrumMaster do all day to justify a full-time role? The following list encompasses most, but not all, of the day-to-day tasks.

I recently wrote about 4 secrets to a successfully daily scrum, which covered the basics for ensuring a productive daily scrum meeting. However, what do you do if your team is distributed?

As I was revising and writing new content for The Scrum Field Guide, 2nd edition, I emailed my friend Bill Hanlon at Microsoft to get his feedback on my existing chapter on bugs. Bill and I worked together years ago and I often value Bill’s opinion more than I value my own. The guy constantly innovates on things that others would say are good enough. Things are never good enough for Bill, and he’s constantly experimenting and trying new things.

We’ve all heard the common myth, Agile means no documentation. While other agile fallacies exist, this is a big one, and it could not be farther from the truth. Good agile teams are disciplined about their documentation but are also deliberate about how much they do and when.

Sprint planning does not need to be challenging. It is often fun and a time for the entire Scrum team to build camaraderie by working together to answer the question of “What can we commit to?” Here I provide examples and strategies for keeping sprint planning focused and effective, and detail potential solutions to common problems teams encounter when planning a sprint.

As I coach more and more teams, people keep saying what they wish they had when they started their agile adoption. Not surprising, there is a pattern here. I looked back at my notes from almost 10 years ago when I first adopted Scrum and XP and, oddly enough, many of the things I hear today are on my list from years ago. Lets dive in.

How to integrate rework into your everyday life while building software and why it’s key to success.

In the world of Scrum it’s fairly common for organizations to quickly jump into practicing the agile methodology and then become frustrated or disappointed when they don’t see significant immediate results.

Agile aficionados seem to have it out for the old faithful waterfall process. For years now, they have claimed that a requirements document can’t ever be complete, that you can’t possibly know everything upfront, and that waterfall’s guarantees of on-time delivery are false. Where do they get these crazy ideas?

Technical interviewing and hiring an agile team can be a challenge. In this video, recorded in January, 2013, Mitch Lacey & Jonathan Wanagel from Microsoft discuss anti-patterns that can lead to corporate dysfunction.

We hear quite a bit that Scrum teams “need” full time ScrumMasters, but rarely do we see teams that get them. Why? Several reasons, but the biggest one is usually money. Why should a company pay for someone to keep a team healthy?

There is no one-size-fits-all, magic bullet for determining a sprint length that works well for every team. Originally, Scrum called for one-month sprints, but nowadays many teams have been successful with two-week or even one-week sprints.

Looking for ways to use agile practices at home? This blog post was written in 2006 but it still applies today. I’ve since expanded it to my other kids (we had more).

I went to Sweden for Microsoft TechDays a couple weeks ago and right before I left I found out my sessions were at the end of the day on both days, which was fantastic! I thought to myself – should I change over to the local time zone, which was nine hours ahead of my home time zone of Pacific?

We put a lot of emphasis on being Renaissance workers, able to step comfortably from one job role to the next. But, as I describe here, not all roles play nicely with each other, and trying to combine them may lead to disaster.