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:
There are three different issues that ShareKhan is talking about:
- Business value of a functional story
- The reason for splitting requirements into stories AND
- 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.
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.
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.
- As a sales person, I should be able to enter the product code by typing it in
- As a sales person, I should be able to enter the product code by scanning the barcode
- As a sales person, I should be able to enter the product code by scanning the RFID tag
- As a sales person, I should be able to make a sale for the product entered
- 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.
3 comments:
I liked your paragraph on Technical "stories". I have noticed that wording these in a story like manner is sometimes indeed not possible. I can't recall an example off hand, though.
Thanks for the post. I've been exploring a lot about the role of the business analyst in an agile environment, so this is a timely post for me to read.
It seems the fundamental issue is that individual stories have value in context of their relationships with other stories. It seems like it would be very difficult to break that value apart into discrete small pieces, even though it probably makes a lot of sense to break those requirements apart for the purposes of implementation.
Our role as BAs has got to be to keep these different layers of stories, meaning, value, and implementation chunks (for lack of a better word) held together in context. And for that reason, I really like your example of selecting 3 stories of 5 because they deliver something meaningful.
Thanks for the insight.
Best,
Laura Brandau
http://bridging-the-gap.com
Hi.
I have read about user stories and how they can be documented using advices like you about them value. I think it’s easier when you use them for user interaction and you have real users. Although in some cases we must build software components and we don’t have real user, instead of we have others systems, interfaces, protocols, metrics, and so on. For our team is more difficult use user stories to describe “enough” (at agile style) all of the thinks related to intangibly components. We are trying to use Conformance section of user stories to describe aspects related to interfaces, performance, availability, readiness, dependencies, and so on
The same difficult we have using uses cases.
Do you have some experience with this kind of user stories?
Post a Comment