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.

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.

Cost Beyond Code #2

Some quick feedback on my rant mainly wanted some examples of a costly situation that is a result of poorly managed requirements.  I'm going to use a lot of "probably's" and "likely's" so just bear with me :P

The Project

• Requirements are maintained in word docs on a shared drive (not Sharepoint) where the filenames are along the lines of "Release - June 2007" that nobody's opened in years.  Essentially, they're practically un-browseable and un-searchable in any decent amount of time.
• These requirements were never formally reviewed by anyone.  People would show those groups like QA and End User Trainers "how it should work" in a 1 hour meeting.
• Developers tend to "own" things where one feature set is entirely done by a single guy.  No recorded code reviews.

The Costly Situation

• Some piece of software has a feature that has been working in production for a couple years.
• An odd behavior comes up it is keeping an order from being Billable.  For arguments sake, it is a scenario that hasn't come up in an extremely long time and there's no documentation in the IT Ticketing system of how this was resolved the last time.
• The guy who coded it is no longer with the company.
• None of the "expert" users know how the software SHOULD react in the given scenario.

Cost #1: Operations

The earlier you have that money in the bank, the earlier you're making more money for you.  If this is visible to the customer, you run the risk of their simply cancelling and going with a competitor.

So let's say this IT ticket rises through the different levels of support and reaches you, the developer.

Question #1 - Have we ever encountered this scenario before?  What did we do last time?

• If you're pretty immature about your requirements maintenance, chances are you're pretty immature about your bug tracking too.  For me, this is a classic example of a Broken Window phenomenon in a software development project.

Question (set) #2 - Why is this happening? Is it a bug?  Did the requirements cover this when the feature was developed?

There's absolutely no reason for you to look up the requirements.  You're not going to try to wade through 10's or even hundreds of Word docs that were meticulously documented but whoever wrote them didn't really think about how to reference back to them.  If you're not a developer, the one thing left to do is at least dork around in the stage environment to reproduce the issue.

Cost #2: Support Investigation

Even if the issue is reproducible, without the requirements from when this feature was developed, you probably can't answer the question "is it a bug?"  "Why is this happening?"  Without the context of the requirements, reproducing the issue can be a significant challenge.

You're still going to need a developer to look into this.  However, it is extremely likely that in this scenario the first 2 questions aren't even asked so one could argue that this cost in labor isn't even accrued.  :P

OK DEVELOPER SAVES THE DAY.  Not Really.

Ok you're investigating the code to answer Question #2.  You're likely wading through code you're unfamiliar with.  At this point a lot of people will argue that this like ability of the investigator, coding conventions, and quality of code will impact how efficiently this investigation will be accomplished.

Question #3 - What is the context of this code?

Commit messages can help.  Code quality can help.  However you likely don't have any linkage from a commit message to the actual requirement.  That would come in handy, but like we said, that stuff isn't there for you.  So the differentiation between "this is by design" or "this is a bug" is close to impossible.  It's going to take you some time to figure out what's going on in the code, describe it to somebody, and hopefully have a solution on what the user should do to keep the Order moving forward.

Cost #3: Developer Support

What could have been answered from a requirements lookup has now extended to any other full-up bug investigation in reproducing an issue and passing it onto a developer.  You're going to have some back and forth between the developer and others in terms of trying to answer "why is this happening" question.

Question #4 - Is this by design?

You can't tell.  Chances are this will be dependent upon your opinion of the guy who wrote it.  Either way, it's going to be pretty hard to answer this question.  It will be up to some pointy haired person to decide that it is a bug that needs to be resolved right away in the code, that the business needs to update their procedures to be aware of this scenario, or that some behavior change is required to go through some other channels of funding.

Cost #4: Aftermath - Because you haven't come up with what the requirements were at the time the feature was implemented, you can't hold the business accountable for what discussed, reviewed, and implemented.  It is generally easier to get a customer to swallow the "this is by design" story if you have the documentation to back yourself up and simply update their processes.  

Some people will say that some email will be required to accomplish this but that's in lieu of a decent requirements tracking system.  Without this documentation, you're likely going to take up some time to discuss whether it's a bug (money from the IT Bucket) or a new feature that needs to be implemented (money from the Business Bucket).  

Either way, in order to move forward, the relationship between business and IT runs more smoothly if the conversation goes down the path of "ok now we know what the thought was when we implemented this, but we'd still like to submit a change request," vs. "we're going to just have to agree to disagree so what are we going to do about it?" 

There are a lot of pieces that need to be in place to reduce all the costs identified.  However, requirements that are clarified, reviewed, and traceable are key to making all those pieces be in place (and alleviate the cost of that too).

A common reaction of all of this is "Documentation is always out of date when the code is implemented"

This is what User Stories in a Scrum process are meant to alleviate.  I'll talk about this in some User Story post, but I'm already getting requests for describing the costs of getting a Release out after a Release Candidate has been cut so that might just be my next post.

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.