Home
jonathan Babcock's Library tagged → View Popular
Breaking Down Epic User Stories
The reason we want stories to be a particular size is so that they can be developed and tested within a single iteration. We also need them to be manageable; if a story is too big it can be difficult to ensure that everyone in the team has a full understanding of it, and chaos ensues (trust me I’ve been there). Plus, large stories are difficult to estimate to any degree of accuracy.
Can use cases be used in agile?? « Agile Blog
Some of my agile coaches in the past argued that use cases should not be used at all. I disagree respectfully. As use cases and user stories are in essence a verbalization of the requirements from the point of view of the actor or user, I argued and proved that they can be used to populate an agile product backlog.
Alistair.Cockburn.us | Why I still use use cases
Alistair Cockburn's treatise on why he prefers use cases over the user story and product backlog.
MadDog: Why "As a" in User story template is important
It gets interesting if two different persona (different users) find a given feature of software contradictory. I was thinking about one today, where we worked with one group and same story could cause whole bunch of unintended activities for other groups.\n\nIn software development process people write stories in the similar manner that a filmmaker make a blueprint of a movie by constructing story board.\n\nEach feature is captured as a "story", which defines the scope of the feature along with its acceptance criteria. The narrative should include a role, a feature and a benefit.
Use cases - User Stories: so precious but not the same ! | Agile UX
Use cases and user stories are two popular ways to capture functional requirements. They’re both goal-oriented (a very good thing), can be discovered during user / customers workshops, can be easily combined with UX activities, and are used in Agile contexts.
Use cases and user Stories look similar; actually, they’re different. Here is the list of 14 major differences I’ve noticed:
User Stories and Use Cases | Tyner Blain
User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first. They differ from use cases in some important ways, but share more commonalities than you might think.
Six features of a good user story - INVEST model renewed | Agile Software Development
User stories are the the most used format for agile requirements. The main point of the user stories is to focus on the concrete user needs and not on figuring out the extensive amount details that are known to be difficult to gather upfront. A usual recommendation for stories to make more sense is to follow the INVEST acronym popularized by Mike Cohn in his books on user stories and on estimating and planning . According to these books and various online recommendations a good user story should be:
* Independent
* Negotiable
* Valuable
* Estimatable
* Small
* Testable
Qualities, User Stories and sad state of Scrum requirements
User stories are fine for functional requirements, but they are completely useless for quality requirements (aka non-functional requirements). Many teams I work with new to Scrum often start writing user stories for new features, but either pretend the quality dimensions don’t exist or think the architects will magically handle it.
Agile Game Development: Hours vs. Story Points
One of the key values of User Stories is that they can be estimated. Estimations are made using "Story Points". Story Points are a relative measure of feature difficulty/complexity that are useful for planning. If one feature takes twice as much effort as another, it will have twice the story points. As it turns out, Story Points are a more accurate measure of project velocity and release schedule than using hours and days.
-
One of the key values of User Stories is that they can be estimated. Estimations are made using "Story Points". Story Points are a relative measure of feature difficulty/complexity that are useful for planning. If one feature takes twice as much effort as another, it will have twice the story points. As it turns out, Story Points are a more accurate measure of project velocity and release schedule than using hours and days.
-
"Hours and days" attempt to not only estimate the effort of a feature, but also the velocity of the people working on it. With Agile Planning, we separate those two measures. We estimate the effort of the feature in isolation and emperically measure the velocity of a team that is doing the work. There are many benefits of doing this. They are separate numbers that come from separate factors!
MF Bliki: UseCasesAndStories
Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories break requirements into chunks for planning purposes.
User Stories
User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document.
Advantages of the "As a user, I want" user story template | Mike Cohn's Blog - Succeeding With Agile™
I advocate writing user stories in the form of “As a <type of user>, I want <some goal> so that <some reason>.” While I consider the so-that clause optional, I really like this template. I want to give three reasons why here:
Selected Tags
Related Tags
Sponsored Links
Top Contributors
Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »
Join Diigo