User Stories Applied: For Agile Software Development

Category: Programming
Author: Mike Cohn
All Stack Overflow 12
This Month Stack Overflow 2


by anonymous   2019-07-21


The answer is "it depends on who the customer is". User stories need to be understandable and if possible written by your customer. If your customer is a developer of component A or B then it would make sense to you both.

However, if the customer doesn't immediately see the benefit of that I would ask "why" I was adding that interface and keep asking "why" until I get to an answer that the customer does understand. Then I'd write the user story so that the customer can understand what is being delivered.

Mike Cohen's book User Stories Applied is very good if you're looking for something more substantial to read.

by anonymous   2019-07-21

Frankly I believe you to be misunderstood as you have mangled multiple Scrum roles into your definition of a "stakeholder".

The classic definition of Stakeholders is that they are people with legitimate interests in the project. Stakeholders are NOT always product owners and they should not be confused with a Product Owners role in Scrum.

The product owner, helps define the backlog of the scrum team, sets priorities of units of work and communicates progress to "stake holders". These units of work are first "validated" with the Product Owner, and usually again in a sprint ending demo / wrap up of the iterations work to "stakeholders".

Customers or users are who your're building software for. They can also be considered "stakeholders" however I would not do so. I personally like to keep a clear line drawn between stakeholders of the project "support / sales / business executives / etc" and "customers / users".

If your just getting into Scrum i would highly recommend the following book:

by anonymous   2017-08-20

As a compliement to akf's answer, I would like to recommend a comprehensive guide, User Stories Applied.

by Sean Chambers   2017-08-20

A very good place to start as far as books are concerned is User Stories Applied and Agile Estimation and Planning both by Mike Cohn. This have excellent examples and good starting points for anyone first coming to agile methodologies.

As far as website resources they are few and far between. Probably a good place to actually start would be searching for those keywords on Google Images as many people take photos of their burndown charts and User Stories. This helped me a lot when starting. Here are some samples: Burndown Chart, and User Stories

Please note however while a burndown chart is a simple report that you run on your current story points left in an iteration, User stories are more complex than that and do require a bit of reading to wrap your head around. Start with User Stories Applied book for that.

Hope that helps!

by Steve Duitsman   2017-08-20

It seems that if you stick with the "plan, do, adapt; plan, do, adapt" idea of agile (iterations, iteration reviews) you would avoid those things by default. BDUF is just so contrary to the idea of agile estimating & planning that if you are really agile, you wont be BDUF automatically.

The purpose of release & iteration planning meetings is to make sure you are adding the most valuable features to the project for that iteration. If you keep that in mind, you'll avoid YAGNI for free.

I would very strongly recommend the Mike Cohn books on agile planning:

  1. User Stories Applied
  2. Agile Estimating and Planning

Update: After your clarification about avoiding YAGNI and BDUF within an iteration...

BDUF...If I felt a feature was not clearly defined before I started work on it, I would create a small "feature" or story to account for the design type portion of the work needed. So that maybe the smaller story has a story point estimate of 1 instead of the real feature's 5. That way, the design is time-boxed into the smaller story, and you will be driven to move on to the feature itself.

To avoid violating YAGNI I would work to be very clear about what the customer expects for a feature within an iteration. Only do work that maps to what the customer expects. If you think something extra should be added, create a new feature for it, and add it to the backlog of work to be done. You would then persuade the customer to see the benefit of it; just as the customer would push for a feature being done at a certain point in time.