We have a problem. Ok, I have a problem. I’m realizing velocity is often being used as a synonym for team capacity. In fact, I’ve done it, too. Don’t think that’s a problem? Well it impacts our forecasting, estimation, team health, and organizational expectations.
Just when you think something is such a simple and basic principle, you realize that the basics are often the first to go and the first to be questioned. Let’s revisit the definition of done and dissect this…Including a very high level take on the GROWS idea.
A product owner should be dedicated to one team. Or no more than two teams working on the same product with the same product backlog. But what about a product owner who we spread across two teams with different backlogs working on different products? We’re asking them to be two people and it’s not sustainable! This product owner told me he was in 17 hours of meetings between the two teams per week (and I added it up and it was true)! For the product owner who should be splitting his/her time between self thought, stakeholder and customer input, and team time, it’s not possible for those things to be equal or sustainable not to mention the loss of productivity when context switching/multitasking. Though unfortunately this is the non-ideal reality sometimes.
Ah, the elusive, well-executed stand up meeting. In my experience, the stand up or daily Scrum is often the first thing we try to implement when introducing a team to Scrum and also the first thing to deteriorate as teams mature or don’t mature. But what actually makes a good stand up and what are some symptoms to avoid for a poor one? I’ve been circling this for awhile now and here is what I’ve come up with – including the ‘eyes closed stand up.’
If you’ve been following my blog and writings you maybe know a bit about my work with User Experience and what I call the UX Runway – UX working an iteration or two ahead of technology to make designs which technology teams can then develop to. One of my co-workers, James Schmittler has written a great piece about what actually happens each day of a two week iteration from the UX perspective during the UX Runway. It gives a great insight into how a typical iteration looks in UX land and some key places where PO and technology integration is needed. It mirrors well with my project management/ScrumMaster perspective on the UX iteration and I’m excited to share it here:
