User Stories - Asking some Questions

If you're looking for me to spell out what specific elements a User Story should have, I'll just point you to test framework called Cucumber where you write "Cukes" to describe the behavior you're testing.  When thinking about how you're going to test something, the User Story becomes pretty apparent.

http://cukes.info/

But rather, when Business Analysts, Developers, Product Owners, whoever is writing user stories, there are a key questions to ask that can drive what your User Story should look like and more importantly, what supplemental information may aid in the development process.

Whose problem are you trying to solve or alleviate?

If this isn't the first question you're asking, you might as well go home.  Now.  You're home?  Step outside.  Walk a block.  Ok.  Go home.  Look at cukes again.  I'm not saying you should be using Cucumber for your test framework, but they have very good ideas.

How can someone validate this?

See the cukes.

Who's Going to Consume Your User Story?  Who participates in the release cycle?  Who are responsible for validating your implementation against the User Story?

To me, these are all the same question.  However, you may get different answers to these questions, depending on who you're asking.  This is something that's very specific to your project and organization.  However, all the people that may be identified as answers to these questions can benefit from reviewing the User Story.  Why is that useful?  How often do you find yourself having to demonstrate a feature to someone to explain to them what the feature is?  How often are THEY then demonstrating it to others to explain to them what the feature is?  Your organization can have a slew of handoffs where a clearly defined User Story can save time and reduce the Telephone Effect.  Here's an overloaded example:

Product Owner -> Developer -> QA -> Training/Documentation -> Support

In a conversation the other day, an IT manager that supports a huge bio-research organization mentioned that the largest challenge towards their adopting Scrum was that [non-developers] think that it's "just for developers."  Without diving any further into the specifics, I feel that this is due, in large part, to some organizations not disseminating User Stories out to non-developers.  In a more Waterfall environment, you may have a very extensive requirements and design document... that nobody reads.

One potential pitfall for a User Story when it's "just for developers" is when someone, in reality, is simply writing a technical task to be done.  With that, I simply point back to Cukes again.

Do you need buy-in for your User Story?

This heavily depends on your organizational culture and how much trust everyone puts into the Product Owner.  However, when seeking feedback, identifying potential gotchas, or simply being able to come up with a better design, answer the following as part of your supporting material can greatly provide food for thought.

• What's the current behavior?
• Why is it not optimal / desired at all?

When working towards buy-in for your User Story, it not only helps people feel more valued, but also increases the organization's trust in your being able to identify the overall direction of the product.

With that last sentence, if not to be more efficient, increase organizational cohesion, and increasing clarity in the process, just simply thinking about these questions when writing User Stories can make your life easier when people trust you more.

User Stories - How they're Useful

All too often, organizations spend a stupid amount of time talking about what information should go into User Stories and how their content should be structured.  They forget to ask the question, what do we want User Stories to do for us?

Typically, people see Users Stories as a tool to answer one question: "What do the developers need to code?"

In a TDD oriented environment and, surprisingly to a lesser extent, when there is a separate QA team, User Stories, people use User Stories to answer the next question: "What needs to be validated to accomplished our goal?"

One question that doesn't get asked, though is "How do we keep the Product Owner accountable for what we produce?"

"That's not what we talked about."

When demo happens, what's demoed may not match what the Product Owner may have in mind.  When this happens, the conversation can quickly devolve into a "well you said..." conversation where there is no record.  This both negatively impacts the team's relationship with the Product Owner and wastes valuable time.

Stories provide a snapshot of requirements at a given sprint.

With a recorded User Story, the team and Product Owner can review the Story, review what was discussed in the story (ideally relatively close to when work started), and move forward.

• What was ambiguous in the Story?
• What Questions did we not ask?  What did we not write down?
• How can we improve on our stories the next time?

By improving the story development process, a team can greatly reduce rework and avoid contentious conversations with the customer.

"Is this behavior by design or is it a bug?"

Far into the future into production support, the User Story can further aid in answering the super contentious question: "Is this behavior by design or is it a bug?"  This is a pretty overloaded question.

• When was this feature originally developed?  
• What was the expected behavior at this time?
• Does the observed software behavior meet this?
• Do current customer processes meet these?

The longer this question is discussed without any hard answers, the greater the negative impact it can have on the Team/Product Owner relationship.  This question also greatly impacts whether the solution will be an End User behavior change, a bug fix (typically paid for by the Team budget), or a new feature (typically paid for by the Customer's budget).

Without these scenarios in mind, User Story development can easily have a Fire and Forget mentality.  This can lead to a lot of avoidable costs and negative impacts on customer/team relationships.  Next time I'll talk about more questions people should think about when performing User Story Development.