Category Archives: Agile

Articles that discuss the agile development methodology. We look at the costs and benefits of agile. We also try and reconcile agile approaches with structured requirements and user experience approaches.

A Prototype is Worth a Thousand Lines of Code

A picture is worth a thousand words.  A prototype is worth a thousand lines of code.  Two key elements of product management – and of agile development are elicitation and feedback.  Low fidelity artifacts can significantly improve both.  Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.

Continue reading A Prototype is Worth a Thousand Lines of Code

Use Cases for Iterative Development

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 requirements for incremental improvement?

Continue reading Use Cases for Iterative Development

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 are important.

Continue reading 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 solve all of the problem for a subset of the users.

Continue reading Sprint Backlog – Don’t Solve Half of the Problem

Foundation Series: Inside A Scrum Sprint

Photo of students in a classroom, learning scrum

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 in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.

Continue reading Foundation Series: Inside A Scrum Sprint

The One Idea of Your Product

a blue light bulb, a visual metaphor for having a single idea

“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 mind almost daily ever since.  Maybe by writing about it I can exorcise the demon and get back to using the idea instead of being haunted by it.

Continue reading The One Idea of Your Product

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” even though it is not your job to design the solution.

Continue reading Design-Free Requirements

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?

Continue reading Agile Prioritization: Which Widget?

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:

  1. Identify the problems that need to be solved.
  2. Explain why those problems are worth solving.
  3. Define when those problems are solved.

Continue reading Concise Requirements