Category Archives: User Stories

Agile Estimation, Prediction, and Commitment

Agile, Business Analysis, Prioritization, Process Improvement, Product Management, Project Management, Requirements, ROI, Software development, User Stories

Your boss wants a commitment.  You want to offer a prediction.  Agile, you say, only allows you to estimate and predict – not to commit.  “Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.”  There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.

This is an article about agile product management and release planning.

Continue reading Agile Estimation, Prediction, and Commitment →

Agile Documentation

Agile, Business Analysis, Requirements, Requirements Models, Software development, User Stories

Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto.  That doesn’t mean don’t document!  It means don’t document more than you need to document.  Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile.  How do you avoid over-reacting when changing a culture of over-documentation?

Continue reading Agile Documentation →

Atomic Requirements

Agile, Business Analysis, Ishikawa Diagram, Prioritization, Product Management, Requirements, Requirements Models, Software development, Software requirements specification, User Stories

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

Agile, Business Analysis, Product Management, Requirements, Requirements Models, Software development, User Stories

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

Agile, Foundation series, Requirements, Requirements Models, Software development, Testing, User Stories

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 →

Measuring Great Design – Mad Libs Input Form

Interaction design, Product Management, Requirements, ROI, Software development, User Stories, UX

image of mad libs pads

I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.

Bonus: the idea is cool.

Continue reading Measuring Great Design – Mad Libs Input Form →

Design-Free Requirements

Agile, Business Analysis, Interaction design, Interface Design, Product Management, Requirements, Requirements Models, Software development, Use Cases, User Stories, UX

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 →

Concise Requirements

Agile, Business Analysis, Ishikawa Diagram, Product Management, Requirements, Requirements Models, Software development, Use Cases, User Stories

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 →

Writing Complete User Stories

Business Analysis, Product Management, Requirements, Requirements Models, User Stories

User stories can make requirements management a lot easier.  They shift some of the communication from up-front documentation to ongoing dialog.  That’s the main reason they work so well for agile teams.  And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?”   The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough.  Add a small dose of traceability, and you can easily validate the completeness of your user stories.

Continue reading Writing Complete User Stories →