People often don’t decide and act rationally, according to studies from the area of behavioral economics. Pierre Hervouet describes how our brain takes decisions, talks about experiments on using personas and the IKEA effect and explains what we can learn from these experiments for agile software development.
Many teams use the Definition of Done to check if a user story is finished and the product is ready to be delivered. But what about the user stories that a team receives from their product owner? Teams can check the quality of the user stories using a Definition of Ready.
Estimations are used by agile teams and product owners for prioritizing work and to plan releases of products. They can be done on different levels and in various ways.
Would better user stories improve software delivery? Gojko Adzic thinks applying small changes to the way teams manage their user stories can have a huge impact on the actual outcomes of their software delivery. He announced that he wants to write a book about improving user stories if at least 5000 people show that they are interested by pre-registering themselves in January.
Organization mostly do an agile transformation for a whole team, project, or organizational unit, given that agile is a team driven approach. But there are also professionals who start using agile practices individually, or who are working agile as a one person team. How can individuals adopt agile, and what kind of benefits can it give them?
When you have a large backlog with many user stories, structuring a product backlog with story maps or process maps can help to keep an overview and see the bigger picture.
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?
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.
Most new Agile teams transition from hours based estimates to relative estimation using story points, but do we even need estimates at all?
Several members of the Agile community describe different styles for expressing user story tests and the testing of an entire theme.
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.
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?
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?
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.
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?