How do you manage activities that don’t seem directly related to features in your Scrum sprints? This blog post discusses why it is a problem when Scrum teams start to wonder about having time to manage infrastructure, technical debt or test framework. For Johanna Rothman this is the sign that the culture is not Agile enough and that the product owner doesn’t want to take iteration time to schedule anything other than features in an iteration. She offers seven hints on how to improve this situation, saying that product owners …

Learn how you can improve your business analysis with Agile story mapping, a technique that maps your stories back to business value. Thus you will be able to know if they make or save the company money and you will learn the benefits of bi-directional requirements traceability
.

The “rightsizing” of user stories occurring during the planning of the next sprint in Scrum is not always an easy task to perform. Inexperienced teams have difficulties to split user stories into smaller chunks that still deliver business value and would rather use technical criteria. In this blog post, “Specifications by Example” author Gojko Adzic provides a new approach to achieve this goal using the hamburger as a reference. You identify the tasks making up a user story. Then you use this breakdown to identify different levels of quality for …

Estimating and planning are critical to the success of any software project, also in the case of distributed agile development. Research has acknowledged that conventional agile methods need to be adjusted when applied in distributed contexts. However, we argue that also new tools are needed for enabling effective distributed agile practices.
This article presents eConference3P, a tool for supporting distributed agile teams who applies the planning poker technique to perform collaborative user story estimation. The planning poker technique builds on the combination of multiple expert opinions, represented using the visual metaphor …

Epics are used to get a bigger picture of user stories, but we need another level of abstraction. We need to bring together the various Epics that describe how our solution will evolve to its final endpoint, and how different functional teams and specialists will interact.

The Scrum Expectation Line is defined by Zsolt Fabók as the line that follows the expectations of the Product Owner during each sprint. In this blog post, he discusses the difference between the team capacity to deliver and what the Product Owner wants in each Sprint and explains how his team deals with it.

This article describes a Lean and Scalable Requirements Information Model that extends the basic team‐based agile requirements practices to the needs of the largest, lean‐thinking software enterprise. While fully scalable to all levels of the project, program and portfolio levels, the foundation of the model is a quintessentially lean and agile subset in support of the agile project teams that write and test all the code.

Henrik Larsson presents in this post the user stories lifecycle from their origin in a Minimum usable feature (MUF/MMF) to their validation by the product owner at the end of a Scrum sprint.

In this blog post, Sten Johnsen discusses the impact of moving uncompleted user stories from one Scrum sprint to another. He focuses on the unfinished user stories, its impact on the team velocity and its influence on the ability of the team to change.

This article provides an overview on the derivation and application of user stories, which are the primary concept that represent the user requirements in agile software development approaches like Scrum. Its goal is to describe the user story in detail, because it contains the key agile practices that help align solutions directly to the user’s specific needs, assuring quality at the same time.