You are currently browsing the tag archive for the ‘user stories’ tag.
Take a look at two versions of a User Story, which are written using Mike Cohn’s popular format:
Version 1
As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.
Version 2
As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.
There are two words added in the second version of this User Story that could potentially derail the development effort if ignored. It’s easy to overlook adjectives and adverbs as adornments that don’t add value. While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.
Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements. The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes. This also aligns with popular practices of Thomas Gilb.
| Adjective/Adverb | Promptly | ||
| Target | Account balance calculation process | ||
| Measured by | Number of manual steps required | ||
| Minimum acceptable | 1 | ||
| Maximum acceptable | 4 | ||
| Measured by | Time from submit until calculation appears | ||
| Minimum acceptable | 0.5 second | ||
| Maximum acceptable | 3.0 seconds | ||
By now, the Scrummers out there may be squirming, but hear me out. The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes: 1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.
I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself. This could feel like squeezing a square peg in a round hole. A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”. The deliverable for these tasks could potentially conform to the format I described above.
Advertisements
Take a look at two versions of a User Story, which are written using Mike Cohn’s popular format:
Version 1
As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.
Version 2
As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.
There are two words added in the second version of this User Story that could potentially derail the development effort if ignored. It’s easy to overlook adjectives and adverbs as adornments that don’t add value. While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.
Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements. The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes. This also aligns with popular practices of Thomas Gilb.
| Adjective/Adverb | Promptly | ||
| Target | Account balance calculation process | ||
| Measured by | Number of manual steps required | ||
| Minimum acceptable | 1 | ||
| Maximum acceptable | 4 | ||
| Measured by | Time from submit until calculation appears | ||
| Minimum acceptable | 0.5 second | ||
| Maximum acceptable | 3.0 seconds | ||
By now, the Scrummers out there may be squirming, but hear me out. The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes: 1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.
I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself. This could feel like squeezing a square peg in a round hole. A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”. The deliverable for these tasks could potentially conform to the format I described above.
I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.
So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.
From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it’s assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?
Just because I’m Agile, doesn’t mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision – If I don’t write down or draw models of the software I need, I’m bound to forget. What tends to be lost on a lot of new Agile adopters is: It’s okay to write things down, just don’t try to write down absolutely everything before you start building.
I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.
So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.
From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it’s assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?
Just because I’m Agile, doesn’t mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision – If I don’t write down or draw models of the software I need, I’m bound to forget. What tends to be lost on a lot of new Agile adopters is: It’s okay to write things down, just don’t try to write down absolutely everything before you start building.
On Tuesday at ProjectSummit/BA World, I was invited to be moderator of “Agile Analysis: Can it Work at My Organization?” During and after that session I had numerous discussions centered around this recurring question: “What Should I Document, and What Can I Document?” There’s a common perception that on an Agile project, the only thing I’m permitted to write down is a User Story – the remaining communication occurs through verbal interaction. If Agile is all about effective communication, is it presumptuous to assume that verbal communication is the most productive? In 1956, George Miller proposed a theory that the capacity of a human’s short-term memory is seven plus or minus two things. This was proved, and has been proved and re-proved many times. To free up short term memory to make room for the next batch of information, I have four choices: discard it, pass it to someone else and be done with it, encode it in long term memory (this takes time), or write it down. On a project aimed at building anything larger than small and trivial, chances are that if you don’t write things down they will be lost or forgotten. So, the remaining question related to project efficiency is, “If I write information down, what form works best, what do I do with it once it’s written, and what should I do with it after we are done using the information?”
