(I updated this post in May 2025 to more carefully describe what I mean by collaboration and how that differs from cooperation. I struck through collaboration when I meant cooperation.) A colleague asked mobbing last week on Twitter. Here’s the short answer, including pairing so you can see everything in one place: Swarming has a […]
I’ve been the technical editor for agileconnection.com for the past five years. It popped up to my LinkedIn network. Several people congratulated me on my work anniversary. I have learned many things in the past five years: Sometimes, people need “permission” to write what they feel. (They’re concerned they will be too bold, too loud,
When I think of POs and the team, I think of learning in several loops: The PO learns when the team finishes small features or creates a prototype so the PO can see what the team is thinking/delivering. The team learns more about its process and what the PO wants. If the Product Manager sees
Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. This part is about ranking. If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You
Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. Part 3 was about ranking. In this part, I’ll discuss the product owner value team and how to make time to do “everything,” and especially how to change
When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take. Oh, and the POs want to change things as soon as they see them. I don’t see this as problems.To
In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.
If you’ve been following the conversation, I discussed in Part 1 how I like agile roadmaps and gross estimation and/or targets for projects and programs. In Part 2, I discussed when estimates might not be useful. In Part 3, I discussed how estimates can be useful. In Part 4, I discussed #noestimates. Let me summarize
I have two online workshops starting in late August: Practical Product Owner Workshop: Deliver What Your Customers Need Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation If you have been reading the estimations posts and are wondering, “How do I help my project deliver something every day or more often,” you should
When we think about the discussion about estimates and #noestimates, I have one big question: Where do you want to spend your time? In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s