Back in Part 1 of this series, I explained all the problems I saw with this interview question: “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. […]
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
Lisa, an agile project manager, dutifully completed her project status deck every iteration to send to her leadership. She hated creating that deck for several reasons: she knew the data she reported wasn’t the data the senior leaders needed. Some of the leaders still wanted to know the schedule variance—which made no sense in an
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,