user stories
User Stories Key Dimensions
This article discusses the three dimensions of user stories: the backlog order, the complexity (or effort) and the business value. These dimensions are flexible until the sprint commitment, but right before it, you should have estimated the complexity and the business value for the top of the product backlog, which means that the product backlog […]
Read More
Agile Software Requirements by Dean Leffingwell
The title of one of the initial chapters of the book “Agile Software Requirements” by Dean Leffingwell is “The Big Picture of Agile Requirements”. This emphasizes that agile requirements are more than user stories on a small card. In this book, Dean Leffingwell presents the big picture of agile requirements, together with the small details that […]
Read More
Functional Requirements Are Not Always User Stories
What happens when Scrum projects do not have clear user stories? Because Product Owner has the subject matter expertise and decision making capabilities, that does not mean that he can clearly communicate the requirements in a way that will make the developers/testers as productive as possible. This blog post explains that the best way to […]
Read More
User Stories Lifecycle
In this blog post, Henrik Larsson explains the lifeycle of user stories from the Release planning meeting to the release tracking stage where the product owner checks if the release date and contents can be kept.
Read More
A User Story Primer
This article explains the application of Scrum user stories. In agile development, the user story is a lightweight and more nimble substitute for what has been our traditional means of specifying software requirements – software requirements specifications, use case specifications, etc.
Read More
User Story Length
Story writing is usually taught now as a singsong “As a I want so that .” The writer should then immediately document acceptance criteria in the form of a constraint list or automated acceptance tests. Many consider it poor form to create a story that someone outside the team can’t understand from its documentation alone. […]
Read More