|
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.
|
|
|
Know Your Customers: They Can Help You Write Better User Stories Too many user stories begin, "As a user …" Who is your user? Or, more accurately, who are they? Improving your understanding of the types of customers who use your software lets you see multiple products where previously, there was only one—and identifying dedicated products will help you prioritize and accelerate delivery.
|
|
|
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).
|
|
|
ADC West 2015 Keynote: Lean UX: Turn User Experience Design Inside Out When developing products, features, and enhancements, you have to have your customers’ best interests at heart. “We’re not just creating software,” speaker Jeff Patton said. “We’re changing the world.” You need to better understand the people you’re building things for, and the only way to do that is to spend more time with them.
|
|
|
Agile: Don’t Worry, It’s Natural Although the idea of repeatedly exercising the full development lifecycle on smaller chunks of the requirements is newer to the software industry, it isn’t at all new to many other aspects of life and nature. We have been agile practitioners for quite some time, and the software development industry is just catching up. John Ryskowski addresses a few examples.
|
|
|
An Experience Where Agile Approaches Helped This article addresses a process where a team moved from a traditional waterfall model to using agile elements in order to deliver a product to a government agency. It talks about typical problems that come up in a transition to agile, complications from distributed teams, and the advantages and disadvantages of the process for government or nongovernment clients.
|
|
|
Automation Test Suites Are Not God! In today’s age of tight deadlines and accelerating delivery cycles of software, test automation is surely favorable for the world of functional testing and critical to the success of big software development companies. But its various benefits have led to unrealistic expectations from managers and organizations. This article highlights the role and use of automation in an agile context and the irreplaceable importance of manual testing.
|
|
|
It’s Time for Requirements Craftsmanship Holly Bielawa explains that being a a requirements craftsman means that you need to test your assumptions in real time while developing a product. Then you pivot as needed, change your business model as you learn, and constantly get out of the building and gather data to determine your minimally marketable product.
|
|
|
Using Goals, Objectives, and Assumptions to Model Value (or Not) Kent McDonald writes that identifying objectives and the assumptions underlying them provides you a way to measure whether the result of your project will actually get you closer to what you are trying to accomplish, as well as the impact your various assumptions have on reaching that objective.
|
|