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.
Friday, September 19, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
Why do we need to see the business value attached to the story? I assume that it helps to decide the priority of work that should be taken first.
If a story alone doesn't make enough sense, we should try to find the value for the EPIC.
In that situation, the customer can give priority (= business value) only to EPIC and not to individual stories. You shouldn't gain any business value unless you complete the EPIC.
Now, let’s talk about tasks with no business value. You should agree to me that the customer can always provide priority at EPIC level, but we need to complete some non-functional tasks too before we can complete the EPIC. These tasks should be identified for planning.
The summary is: Priority is different from planning. Priority is only one of the data attributes that is used for planning. If you can do your planning without tracking those tasks like "setting the machine", then go for it.
Agree with Rajiv. To me the definition of a 'story' is fluid. Many times it's just logical break down of a high-value Epic, so that it's easy to build & test, which is still valuable though not revenue generating by itself.
About Tasks: What I've seen is that customers tend to use the word 'story' for anything they want to track & monitor. It's just that they see that it's easy to track a task to completion in the same way a story is. So it's more the 'Card Wall' technique that makes them use 'stories' for un-story like tasks.
Post a Comment