Why Story Points are Cool

Sure.  Dilbert Comic.

So to carry on the conversation where some people are saying that estimates, in general, are a waste of time, I'd like to cover some situations where having Story Points are particularly useful.

Do we agree on the requirements?
You really shouldn't need an excuse to drag product/business end users, qa, and developers to have one last sanity check on some requirements.  Getting everyone to agree, at the very least, what the requirements ARE and taking the next step to cover some technical detail as to what the effort would be.  You definitely don't want "the expert" to do the estimation as this is a method of risk mitigation of "expert getting hit by bus."

Do I have enough ready-to-work Stories in the Backlog?

As a product owner, you need to know whether you have enough stories pokered and agreed upon by the team for the next sprint.  This is dependent on knowing your team's average velocity, whether people are going to work vacation days, etc.

Also, depending on your team's process, a Product Owner can ensure that the backlog consistently has a decent amount of low point stories that the team can incorporate into their own sprint.  This is for teams that have the rule that a developer can bring in a story after the sprint start only if they think they can complete the added story within the same sprint.

When are we done with Planning?
Pretty much exactly the same thing as the previous point.  More importantly, when can you end the planning meeting?

Where Story Points don't help:
One scenario where Story Points may just be superfluous, and that is when a team typically breaks a story down to the point where they are all essentially equivalent levels of effort.  This exercise is particularly useful for teams with extremely short sprint times.  This all depends on what your team wants to accomplish and how they want to accomplish things.  However, if just about all stories are broken down to 3 point stories, you are still running through the exercise of Pokering, but rather than asking the question "what's the level of effort for this story," you're asking "is this story a 3 or not?"

... but don't get too focused on those Points

It's really easy to latch onto some quantitative value and to start drawing conclusions.  People are going as far as to asking "why are we FAILING our COMMITMENT?!"  In the end, Story Points are just a tool to help us answer the following, but not used as the ONLY metric to answer:

• Are we meeting customer expectations?
• Is there any action we can take to improve?

This is really hard to drive home for a lot of people and you're likely going to have a couple "electrolyte" conversations but it is truly worth it.

... but what about our commitment?

Either way, I hope this will provide some ideas for Product Owners in particular in using Story Points to help manage not just their own day-to-day work, but also drive home that it's just a tool to aid in efficiency and identify potential areas for improvement.  We should never become slaves to our estimates.

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.