The Definition of Ready in Scrum. 18 Flares Filament.io 18 Flares × “Ready are you?
What know you of ready?” Says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back”. Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to train as a Jedi for many years to find out. Why Ready Matters The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team cannot create a product increment. What Ready Means A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with Scrum.
An item is testable if there is an effective way to determine if the functionality works as expected. A story is feasible if it can be completed in one sprint, according to the definition of done. What a Ready Story Looks Like Summary. User Story Modelling Tips. 12 Flares Filament.io 12 Flares × User stories are great at capturing product functionality from the perspective of a user or customer: Each user story describes a piece of product functionality, for instance, “As an application provider, I want to register with the application centre so that I can use its services.”
By focusing on a distinct area of functionality, the story allows the team to understand, implement, and test the requirement. This strength is also a weakness: User stories are not well suited to express the relationships between different features and to describe workflows. To show how different stories fit together, I have found it useful to complement user stories with lightweight models, originally invented for use cases: context and activity diagrams. Agile Scenarios and Storyboards. User stories are great at capturing product functionality.
But they are less suited to describe the user interaction in more detail. This is where scenarios and storyboards come into play: Both are great tools to describe the interaction steps. In this post, I explain what scenarios and storyboards are, and how they can be used effectively in an agile context, and how the two techniques relate to user stories. Scenarios in a Nutshell Scenarios and storyboards are great to explore and describe how a user interacts with a product. It’s Tuesday morning, and Mary is working on her computer. The scenario above describes the steps Mary has to take to book a seat on one of our public training courses.
Note that I have tried to make the scenario descriptive and engaging while focussing on the key aspects of the interaction. Storyboards Summarised. Epics and Ready Stories. One of the things I love about user stories is their flexibility.
A user story can be big, medium-sized, or small. This allows us to sketch a product with big stories, and then progressively add more detail and refine them into smaller user stories, as we learn more about how to meet the user needs. But this flexibility comes at a price: I often see user stories that are too small or too big, that contain too much or not enough information. A Product Canvas for Agile Product Management, Lean UX, Lean Startup. A Sample Canvas The best way to understand the Product Canvas is to look at an example.
Image that we want to develop a game that helps children enjoy music and dancing. A canvas for such a game could look like the one below. The sample Product Canvas above contains the product name, the product (or release) goal and the metrics to measure if the goal has been met. The first bigger section states two personas characterising the target users and customers with their needs. The Sections Explained As you have probably noticed, the Product Canvas combines form and function, a structure together with suggested techniques. Name simply states the name or version of the product. Writing Good User Stories » All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership.
1.
Discovering and Describing Nonfunctional Requirements. I don’t know about you, but every time I read the word “nonfunctional”, I feel a yawn coming on, and I start to look for something else to do.
While nonfunctional requirements or quality attributes, as they are also called, may not be sexy, they are still important: They impact the user experience, and they influence architecture and design decisions. Say you are looking for a new car, and you’ve found one that looks great. The car also has a powerful engine, lots of safety features, and a sat nav. But during a test drive, you discover that it’s noisy inside the cabin, the seats aren’t comfy, and the actual fuel consumption is surprisingly high. While the car has all the right features, the driving experience is not great – and that’s due to its poor nonfunctional properties. Another example is the training part of my website. Discovering Nonfunctionals Describing Nonfunctionals I like to capture nonfunctional requirements as constraint stories. Summary.