Product owners have many challenges: They need to keep at least two thoughts about the product: what it needs to be in the near future, and what the organization wants it to be in the (distant) future. Some product owners think they’re supposed to fill out a complete backlog, including all the UI designs for […]
In How Product Goals Make it Easier to Create Sprint Goals and Reduce Feature Factories, Part 1, I started responding to Tom’s interview question. Now that we’ve dealt with the feature factory problem, it’s time to address planning time. Here’s the question again: “The product owner and dev team cannot decide on a sprint goal,
A colleague, Tom, told me about this question he received in an interview: “The product owner and dev team cannot decide on a sprint goal, even after hours of discussion. They (the team) feel that the tasks for the sprint are too varied to manage to a single sprint goal. What should the Scrum Master
Most projects encounter problems at some point, regardless of the size of the team and the people’s capabilities. For example, in a six-person team, TeamA, Tom resigned to follow his wife to her new job. Dick became quite ill and went out on short-term disability for the next three months. And Harry needed significant time
Up until now, when thinking about risks, I defaulted to the risks in the project pyramid. That’s because each project offers different value over the product’s lifetime. (See Product Roles, Part 4: Product Orientation and the Role of Projects for images of why we want ever-increasing product value, but why we might space the projects
I see too many teams feel frustrated because their managers say the work takes “too long.” (The team feedback loop is the inside of the onion for how agile the organization can be. See Multiple Short Feedback Loops Support Innovation.) The longer the work takes, the more pressure managers exert on the team and the
When I sent my newsletter last month, Modern Management: Want Valuable Outcomes? Create Overarching Goals, several readers asked me questions. Why did I differentiate between outputs, outcomes, and benefits? I decided that was worth a blog post. Here’s how I define and use the terms. Outputs By themselves, a customer can’t use an output. We
Hours of Overlap, the First Principle of Successful Distributed Teams Do you work in a building with other people? You might think you’re part of a collocated team. Here’s the test: Is everyone on the team within 30 meters (or seconds) of walking to each other? If so, yes, you are collocated. If not, no,
I had the chance to talk with Andy Kaufman on his podcast, Accelerating Your Agile Journey, PPP 2017. We’ve had the chance to speak informally and more formally on his podcast. This time, we had a wide-ranging discussion. We spoke about many of the ideas in Create Your Successful Agile Project: Learning early (instead of failing
I delivered a webinar called Agile Metrics for Team and Product Progress last week, thanks to the nice folks at Innovation Roots. I had fun and so did many of the participants. One person gave me a new saying about metrics (at the end, during the Q&A): Are you data-driven or data-informed? It’s such a great