Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage […]
Atomic Requirements
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements […]
Sprint Backlog – Don’t Solve Half of the Problem
Every team that transitions to agile faces this problem – some stories are too big to fit in a single sprint. Most of the teams that I have worked with have the wrong instinct – to solve half of the problem for all users. The right approach is to first […]
Foundation Series: Inside A Scrum Sprint
People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me. People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work […]
The One Idea of Your Product
“For what one idea do you want your product to stand in the mind of your customer?” I heard Roger Cauvin ask that question at the most recent ProductCamp Austin [correction – he said it here – thanks Roger], and the quote has been jumping to the front of my […]
Most Engaging Articles of 2009
Engagement – that’s what this whole product management blogging thing is about. Check out what Tyner Blain readers found to be the most engaging articles in 2009.
Design-Free Requirements
Design-Free requirements are important for two reasons, and hard for two other reasons. Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” […]
Agile Prioritization: Which Widget?
Your company is building out a toolkit to support third-party developers. You’ll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc. You’ve got a long list of desired controls from your customers. You’re agile. What do you build first?
Concise Requirements
Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things: Identify the problems that need to be solved. Explain why those problems are worth solving. Define when those problems are solved.