User Stories: Value and Size

ShareKhan brought up the issue of story value and size in his recent post here. My comment was getting too long so here's a post.

There are three different issues that ShareKhan is talking about:

1. Business value of a functional story
2. The reason for splitting requirements into stories AND
   
3. The practice of "storying up" technical / environmental tasks

Business value of a functional story
Maximizing work not done is the art of our trade. The business value of a story is looked into precisely for this reason. If you don't have a good reason (business value) behind a given piece of functionality (story), you are wasting time by working on it.

This means that technical necessities, like refactoring of code, also have to pass the business value test to be played. They are not stories by themselves at all. Refactoring happens as part of a functional story which requires the code to change in a certain way.

Splitting requirements into small stories
The basic reason why we split requirements into stories is to deliver working software to the client as soon as possible and get her feedback on it. Development convenience, Better tracking of the iteration progress / velocity, etc are just side effects of having small stories.

Another thing that we aim at doing is delivering value (read "usable software") with every build. This means that if the plug is pulled, the client still walks away with something she can use. Of course, if you pull the plug after the first day itself (like in ShareKhan's example) you won't get much but I guess that's true for anything in life.

What small stories do is they let you build a coherent piece of software that has some value. Let's say we have the following stories.

1. As a sales person, I should be able to enter the product code by typing it in
2. As a sales person, I should be able to enter the product code by scanning the barcode
3. As a sales person, I should be able to enter the product code by scanning the RFID tag
4. As a sales person, I should be able to make a sale for the product entered
5. As a customer, I'd like to get an itemized bill for the products that I bought

I'd have 1, 4 and 5 built first and keep 2 and 3 as niceties. If the client pulls the plug after 3 stories, she still ends up with a system that let's her sell products. Now if you don't do it this way, your client ends up with a piece of software that can take in a product code in multiple ways but can't make a sale. Making a sale is the crux of the system (taking the POS example from ShareKhan's post).

Technical / Environment / Infrastructure tasks and the practice of tracking them as stories
I think my main problem is with calling these "stories", unless you can actually clearly define the value that they bring. Most of the times the value of such tasks is as vague / intangible as your NFRs. You know these tasks are valuable but it's a waste of time trying to find out and put down in words exactly what value they bring in. I don't even think that it affects prioritization of these tasks in any way.

That leaves one problem, tracking and I think we should track them as convenient to the project. Track them as cards, count them in velocity, deduct time spent on such tasks from development capacity. Anything that suits you and the client.

When do you decide that a story has business value?

We were discussing an issue with a client today. It was about getting some hardware installed that involved a series of tasks like getting racks, loading them, having the machines setup with some config and so on. The person in charge of this area was asking for stories to be created for each of these tasks "so that the work could be tracked".

The manager we were talking to was questioning the value of this with the logic that these are just simple tasks that need to be done by one small team to get the machines installed. How will having stories to track this help?

The idea of having a story is to track how delivering upon a small discrete requirement can generate business value for the business. Whats the point of generating more overhead with creating, delivering to and tracking a story for such low level tasks?

Then I thought, how do you quantify this business value per story? If the complete goal is to build a retail POS system, then what business value can I have by just getting a story to work where it lets the user scan a barcode and have the value register? If the rest of the system (and maybe 200+ stories) don't get done or don't work, then the miniscule "business value" of this scanning story is meaningless.

So then at what level does story breakdown make sense? To me, it now seems more of a development nicety to break it down so it fits in an iteration, give closure, blah blah.

Align Software to Business Goal !!

This article stress on understanding the Business Goal on first opportunity available.

Board Room of Chief Technology Officer (CTO) , Star Hotel, London

There were 3 people in the room discussing the need to improve the existing portal of the Hotel.

CTO: Current portal is really slow. I guess that user like to visit our site but they leave the site before all information loaded to the website.

Product Owner: I am not able to showcase new offers efficiently through current website. I need to take approval from two different groups before I can talk to administrator of the portal to load new offers. 90% of time, the administrator ask me to make changes to offer details due to technical limitation.

Technical Architect: It seems that current portal needs to be replaced by a new one. My team can re-write it using a new technology and develop the software based on new requirements to support your needs.

CTO: I would rather like to re-use the current portal. If you need budget to enhance the existing portal, I am ready to get the budget for that. But I don’t want to invest for building a new portal unless really needed.

Technical Architect: If the problem is only to improve the performance and manage the promotions of new offers, we can solve your problems by refactoring some of the code. But, still we need to re-write some part of functionality to accommodate new requirements.

CTO: I am OK with that. So, we are clear on what we need. I want two of you to work together and come back with estimated cost for this enhancement.

CTO: One more Point ! We recently hired a business analyst to help our team on gathering requirements for new software projects. Do you want to involve him on this now?

Product Owner: Na… as of now, we are not clear on what we need. I will work with technical team to get more clarity on complexity of implementing some of my requirements. We can involve the business analyst later.

The Product Owner and Technical Architect worked on understanding the requirements for a month and gave proposal to CTO.

CTO gets the approval from Chief Executive Officer (CEO) and asks team to start the work.

Now, the team decided to bring the business analyst to enhance the functional requirements.

Question
At this point of time, is it possible for business analyst to align the software development work with business goals?

My Opinion
Yes, the business analyst should still be able to work with the team to come up with a new/modified plan and requirement list which is aligned to the business goals, though if the team would have involved her in the initial stages of discussion, it would have been faster and easier.

Question
What if the business analyst doesn’t question to find out the goals for the business and need for developing the software because she got involved late in the process?

My Opinion
It is a big risk. The software might be technically sound but the investment on software may not improve revenue situation for the company. It may also result into the re-write of the portal very soon in near future.

Conclusion
Understanding the business need for the software is important. No matter when a business analyst starts working on the project, she should always start on project by understanding the business goals that should be fulfilled after development of software.

Business analysis and quantum physics

In search of Shrödinger's cat is a wonderful introduction to quantum mechanics. The basic (and intriguing) problem of the elusive electron acting as a wave and a particle at the same time.

Analysis is very much like observing the electron in the classic two slit experiment. The business domain is like a wave traveling through the two slits. But the moment we analyze, we make it boil down to one reality by asking it How, What, When and Who.

Waves give you a probability distribution, while particles give you one of the possibilities as a reality. Looking at a business problem, in the wave form is better since it let's you choose a reality that solves the problem well.

For Example: Let's say the business problem is "I want to let my customers know of the new offers I have so that they can take advantage of the offers and I can make money"

This is the problem in it's wave form. The reality can be one or more of email, website updates, RSS feed of offers, people going door-to-door, mobile advertisement vans and a million other options including telepathy, albeit with low probability perhaps.

The problem is that clients come and say "I want to let my customers know of the new offers I have by email so that they can take advantage of the offers and I can make money" and it takes a while to get into a mode where you challenge every reality and go back to the wave form, by asking "Why"? Why is the only question that let's you go back to the wave form.

The more we procrastinate our observation, the better will the chosen reality suit our problem. Agile takes this approach with the concept of the last responsible moment for a decision. It let's future remain future and hence full of possibilities.

When do you need a business analyst

So I'm working for a client where they practice Agile, but do not have the role of a business analyst. They prefer to have their business users work closely with the development teams, calling this role that of a product manager. The people in these roles are subject matter experts who understand the business very well and have been trained well in Agile concepts.

However, when it comes to working with the development team, its difficult for them to always provide information in the form that developers can consume. At several times, we have seen that the role of an analyst is needed to bring consensus on requirements within the different business groups and to structure and sequence functionality such that the best interests of the project are always upheld.

The work involved is fairly spread across various systems and not contained to a small area. I think that if the latter was the case, then perhaps we could have got by without any analyst role.