Agile approaches have few proposed specific rules or techniques that have become de facto standards. One of these technique is to use the “as a <type of user>, I want to <do something>, so that <reason>” format to define requirements as user stories. In this blog post, Jim Bird discusses the idea that this user stories format is not the best way to manage requirements.
The prioritized product backlog is core to being Agile. A well prioritized backlog allows us to satisfy the customer through early and continuous delivery of valuable software at then end of each sprint in Scrum. Lean and Kanban may call it something else, but there too, prioritized work is key.
In Scrum, the standard format of a user story is easy to understand: “As a [role] I want [something] so that I can [benefit].” However, there is more difficulties inside the project team to agree on what constitute the content of a user story. In this blog post, Steve Johnson explores this issue.
Backlog refinement is an important part of the Scrum team activity as it allows to gain a shared understanding of the work flow. Behavior-Driven Development (BDD) is a technique that use a business language to define acceptance testing (test cases) of requirements. In this article, Zia Malik explains how teams can use BDD to support product backlog refinement.
In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.
User stories are the foundations of the Scrum sprints as they would allow you to work on the right things. Charles Bradley provides a lot of interesting material about crafting good user stories in his Scrum Crazy blog. In a blog post he starts by discussing what a user story is and go right to the point is saying that a user story is NOT a “As a I want so that”. For him, a user story is more than this and should consist of three parts: 1) a written description or short title of the story used as a token for planning and as a reminder to have conversations, 2)conversations about the story that has the details of the story, 3)acceptance tests that that can be used to determine when a story is done.
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 that don’t want to fund technical debt will instead create more of it.
Scrum Expert Copyright © 2009-2024 Martinig & Associates