Articles and Posts 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

How to Be Sure You’ve Thought of Everything

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 here.

A common question I get is how can a product owner (or team) be sure they've thought of everything when writing a product backlog. The question is especially common from teams doing…

Number, Name, Date-Stamp or Sing Your Sprints

Some teams like to number their sprints. Most simply use integers: Sprint 1, Sprint 2, Sprint 3... But I've also seen teams use things like Sprint 1.1 and 1.2 to indicate the first and second sprints of the first release of a product. The second release would start over with Sprint 2.1.

I've also seen teams date-stamp their sprints. A sprint ending on 18 May would be known…

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…

It’s Effort, Not Complexity

A client asked me, "When will my team be done with this project?" This is probably the bazillionth time I've been asked that agile project management question in one way or another. I have never once been asked, "How hard will my team have to think to develop this project?" Clients, bosses, customers and stakeholders care about how long a project will take. They don't care…

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…

Share a Waterfallacy; Win a Book

It seems like time for a new contest with the winner getting a free copy of Succeeding with Agile, my new book. In Succeeding with Agile, I describe a waterfallacy as "a mistaken belief or idea about agile or Scrum created from working too long on waterfall projects." And I give some examples, including these:

  • Scrum teams don’t plan, so we’re unable to make commitments…

Make the Product Backlog DEEP

Roman Pichler, author of "Agile Product Management with Scrum: Creating Products That Customers Love" and I use the acronym DEEP to summarize key attributes of a good product backlog:

  • Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that…

Best Practices Are Dangerous When Adopting Agile

With most organizational change, after someone figures out the right or best way to do something, that way of doing it is captured as a “best practice” and shared with everyone else. For some types of work, collecting and reusing best practices is a tremendous aid to the change effort. An organization that is selling a product to a new type of customer may, for example,…

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.

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).

Incorporating Learning and Expected Cost of Change

An experience report presented at XP2006 covering why it is not as simple as telling product owners to "prioritize on business value." This experience report presents additional factors to consider when prioritizing.

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.