tagged: customers

Simplify Prioritization into “Now” and “Not Now”

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason,...

4 Reasons to Include Developers in Story Writing

Participants in my Certified ScrumMaster courses are often surprised when I recommend that programmers participate in story-writing workshops. After all, a story-writing workshop is a meeting targeted at determining the functionality to be built next. I like to do story-writing workshops about quarterly to focus on bigger initiatives. But some projects will do story writing every sprint.

Regardless of how often these meetings occur, I think it's vital that programmers, testers, database engineers,...

Building a Product Users Want: From Idea to Backlog with the Vision Board

Vision and Backlog

Scrum is a great framework for building a product with the right features. It encourages the use of a vision shared by the product owner, the ScrumMaster, the development team, and the stakeholders, and it provides a product backlog that allows the team to move towards the vision by creating

Two Examples of Splitting Epics

A Scrum trainer recently asked for a couple of good, real examples of large user stories (epics) being split into smaller stories. I thought it would be useful to share those examples here as well since the companies where these came from gave me permission to share them.

Example 1: Selecting Marketing Campaigns

This first example is from a company that sells software to…

Rapid Feedback and the America’s Cup

It's summer and I've been thinking about sailing. I didn't get to do any this summer, but I can still think about it. Thinking about sailing reminded me of the 1995 America's Cup race between the US and New Zealand. That race is a great illustration of the importance of both getting close to our customers and of rapid feedback.

To design their boat, Team New Zealand made use…

Separate Estimating from Committing

A fundamental and common problem in many organizations is that estimates and commitments are considered equivalent. A development team (agile or not) estimates that delivering a desired set of capabilities will take seven months with the available resources. Team members provide this estimate to their manager who passes the estimate along to a vice president who informs the…

How To Fail With Agile

Not everyone involved in an agile transition wants the change to be successful. This tongue-in-cheek article details twenty things you can do to sabotage an agile transition. Of course, the twenty things also serve as reminders of things to avoid or watch out for.

The Chivalrous Team Member

In seeking to improve how we develop software, we continually inspect and adapt. While thinking recently about the characteristics of the ideal team member, we found similarities between the best-performing soft- ware teams of today and the Knights of the Round Table. This article considers the Code of Chivalry as applied to team members.

Do Products Owners Evolve As a Species?

I recently read an article about how fire ants have evolved such that some ant colonies now have two queens. This has helped fire ants spread and more densely populate certain regions of the United States. If a queen who insists on being the sole monarch is born into a densely populated area, she is likely out of luck. But, a queen fire ant with the genetic adaptation that…

Should Companies Measure Productivity in Story Points / Ideal Days?

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point--when trying to decide between calling something “two points” or “three points” it is clear they will round up if they are being evaluated on productivity as measured by the number of story points (or ideal days) finished per…

Writing Contracts for Agile Development

User stories are a great way to get people talking about requirements. However, there's a reason why we invented the written word: to make sure that nothing we've said is forgotten or misunderstood. This article explains why contracts are a good way to capture not only the user stories themselves but also to spell out what constitutes the successful implementation of each story.

The Certainty of Uncertainty

If the only certain things in life are death and taxes, why do so many teams think that if they plan well enough they're somehow going to add software to that short list? This article deals with the mistakes team make when they try to account for every potential need and how best to plan for those things that users don't even know they want (or don't want).

I Didn’t Know I Needed That!

Products that do everything they're supposed to do and offer consumers something they like, but didn't know they wanted, make customers happy. And that is what most of us in software development ultimately need to accomplish. But how do you separate the must-haves from the bells and whistles? And how do you make sure you're including the right bells and whistles? This article gives you clear advice on how to determine which features to include in order to meet and exceed your end users' expectations.

Distance Remaining Is More Important than Distance Covered

With no land in sight to guide them, it would have been all too easy for early sailors to get lost in a seemingly endless sea. All too often, software projects also lose sight of when and if they'll reach their destination. This article explores what ancient mariners knew about navigation that we can apply to charting software project progress.

Stop Listening to Your Users

Users are often kept at arm's length. We ask them for their input on the design, but then we, as the experts, take it from there. This article asks you to bring users into the design process as participants rather than simply as founts of information. You might be surprised at where it takes you.

Introducing An Agile Process to an Organization

The transition from a plan-driven to an agile process affects not only the development team members, but also other teams, departments, and management. In this article we describe common pitfalls and effective approaches to making this change.

The Need for Agile Project Management

Ken Schwaber and I co-wrote this article to help counter the misperception that agile projects do not need project management. The article outlines some of the responsibilities of the agile project manager.

Instant Access

Sign up to get Mike’s blog posts delivered right to your inbox as they publish.

Sign Up Now