InfoQ Homepage User Stories Content on InfoQ
-
Should You Create User Stories for Technical Debt?
Agile teams sometimes struggle with the planning of pure technical tasks that have no direct value for the user of a system, but have to be done to deliver working software. Should you create user stories to handle such technical tasks and technical debt, or not?
-
New Scrum Kickoff Planner Aims To Help Agile Teams Start on The Right Track
A new "Scrum Kickoff Planner" has just been released by Adam Weisbart with the aim of facilitating team discussion around the important facets of starting a new Agile team or project.
-
Is it Time to Stop Estimating User Stories?
Most new Agile teams transition from hours based estimates to relative estimation using story points, but do we even need estimates at all?
-
Representing Agile Testing
Several members of the Agile community describe different styles for expressing user story tests and the testing of an entire theme.
-
How To Split User Stories
Many new Agile teams have difficulty splitting their user stories small enough to work well with Agile techniques. In several articles, members of the Agile community provide guidance on how to split user stories effectively.
-
Do Use Cases Have a Place In Scrum?
In Scrum, requirements are commonly expressed as user stories. But is it OK to also make use of use cases in Scrum? And, if so, under what circumstances should you do so?
-
Who Wants This User Story?
Some user stories defy easy assignment of their benefits to a particular person. But how can we satisfy the standard "As a ... I want ... so that I can ...." user story template if we can't express who wants this work done?
-
Re-estimate Completed User Stories for a More Accurate Velocity?
In a recent thread on the Scrum Development mailing list, Paul Battison asked whether his team should re-estimate completed stories after the sprint is done, so as to have the team's velocity reflect the actual effort that went into completing the stories.
-
Consistently Not Done, Done, Done at the End of Sprints?
Do you consistently have stories that don't meet your "definition of done" at the end of your sprints? Is the team tieing the hands of the product owner?
-
Repetitive Tasks an Agile Smell?
Is slicing stories in horizontal tasks an Agile Smell? Is this common habit used in Scrum/Agile Planning meetings - hurting a team's focus on customer value? What is being suggested instead?
-
Scrum Gathering: Community of Practice
The Agile community is developing consensus around three important areas of practice: requirements gathering, agile coaching, and open space formats for group learning. At the recent Scrum Gathering, these topics were prominent topics of discussion on Day 1, Day 2, and Day 3 of the event. InfoQ explored each of these further to gain a better understanding of their place in Agile.
-
Interview: Jeff Patton on Embracing Uncertainty
In this interview with Jeff Patton at Agile 2008, he talks about three strategies that can help product owners do their job more effectively by embracing the inherent uncertainty in all software development. Namely they are understanding the ultimate goals of the project, delaying decisions until the last responsible moment, and scaling up by building quality.
-
Story Mapping Gives Context to User Stories
The Scrum notion of 'backlog' is a single, prioritized list of user stories for the team to implement. This works well for organizing what the team should work on in the near term, e.g. during sprint planning. At the Orlando Scrum Gathering, Jeff Patton described story mapping. This is a way of organizing stories that provides richer context and can help with release planning.
-
Being A Better Product Owner
Anyone who has spent any time on an effectively executed agile project can attest to the fact that the Product Owner's (or, in XP, the "Customer's") collaboration with the development team plays a key role in the success of a team. Peter Stevens offers a bit of advice to help people in these roles do this well.
-
Use Cases Considered Valuable (but Optional) For Lean/Agile Requirements Capture
Dean Leffingwell, author of Scaling Software Agility and Chief Product Methodologist at Rally, has concluded that Use Cases can be a valuable tool to model requirements for a large-scale Lean/Agile Project. Use cases are not commonly encountered in Lean/Agile (especially XP and Scrum), where stories are the requirements gathering tool of choice.