|
Estimating Business Value in the Shark Tank You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.
|
|
|
Business and Development: Working Together to Build Better Products Business stakeholders and DevOps teams both have to take an active approach to app development, but neither faction should have to change practices and processes in order to get their needs across. Investing the time to establish communication between these teams will drive delivery of the applications customers demand.
|
|
|
Who Is the Real Product Owner? Communication is always vital on an agile project to ensure everyone is on the same page, but it's perhaps most important in a relationship between a vendor and a customer. Here, Marcus Blankenship relates a personal story about a project where communication failed, and gives some good tips for how to avoid it happening to you.
|
|
|
When Prioritizing Stories, Don’t Forget the Stakeholders Instead of choosing what to develop based solely on a cold, hard dollar amount, you might try approaching the person who originally requested a story—or who will be most affected by it—and asking, “What benefit will this bring you?” Armed with a list of stakeholders and interests, you can find out the real difference a story will make.
|
|
|
Assessing the Business Value of Agile User Stories Allan Kelly says that ideally, companies should put a dollar amount on each planned business decision. But pinning down financial value can be hard, and besides, there are many other factors to consider, such as sustainability and customer service. He looks at various ways to assess the business value of user stories.
|
|
|
Product Owner, Product Manager, or Project Owner? If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.
|
|
|
Stories, Epics, and Tasks: Organizing Agile Requirements Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.
|
|
|
How Business Teams Can Embrace Agile Techniques As agile principles and practices receive greater organizational exposure, business teams are embracing certain aspects of agility that were traditionally reserved for technology teams. This article details the experiences of a group of people with business roles who have adopted some agile methods and how their teams have benefitted.
|
|
|
Relieving Agile Tension: How to Write Small Stories That Still Have Value There are two practical goals for user stories: Each story should be beneficial to the business, and each story should represent a small piece of work. However, there is tension between these rules, and they often push in opposite directions. This article discusses how to keep stories small and tasks manageable, while ensuring they retain business value.
|
|
|
User Story Heuristics: Understanding Agile Requirements Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person—be it the product owner, business analyst, product manager, or someone else—embodies the understanding of what is needed, and the user story represents the work that needs doing. This article details what user stories are (and what they are not).
|
|