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.

Costs of Software Beyond Code

So I might as well end my blog posting drought with a stupid gripe.

The software development cycle is but a small subset of the actual software product release cycle.

Sure, a lot of people are talking about Agile processes and getting a new release every sprint and whatnot but cutting a release for most software development teams means the following:

• We have some features developed!
• It's passed some sort of regression testing!

Especially in larger organizations, this is far from what's required to get a release out the door.

I work for a company where the developed software typically has 3 types of consumers:

• Developers within and outside the company
• A couple hundred marketing/accounting/operations folk who are in the same physical location as us
• Thousands of marketing/accounting/operations folk that are scattered around the country

Oh by the way, bullet two govern rules for bullet 3.

Coming from a large "systems of systems" integrator-esque company, it comes as a surprise to me how little care people take for delivering to another developer team.  Of course, they care when they're at the butt-end of the stick.

However, what's even more surprising is when a team isn't aware of all the work involved once a release has passed QA.

Especially for those thousands of folk scattered around the country, there's a boat load of preparation going on.  Training material, help documentation, videos, webinars, and conference demos are done to ensure that major features or even changes to existing features are flowed out and can be referenced in the future.

... and THEN there's the support and any issue investigation in production.  

The amount of personnel devoted to this is practically the same headcount as the development teams.

The absolute worst thing any team can do is simply provide these people some new features and say good luck!  No release notes.  No Requirements that fed into this.  Nothing.  Else.  Awesome.  You just tripled the cost of all the post-development work.  You probably tripled the cost of QA since you probably did the same to them as well.

I am of the firm belief that solid requirements that are reviewed early on by everyone in the release cycle is the key to efficiency in any software project.  The key words being reviewed and everyone.  It's pretty much everyone's responsibility to ensure that this happens as early as possible.  Unfortunately, what happens a lot is that everyone pretty much throws their arms in the air saying that it isn't their job and a combination of snowball and broken window effect happens.

I'll try to talk about a Shangri-la scenario in a Scrum perspective and also talk about what the overall deliverable set should be.

When I get around to it.