A Product Owner is constantly balancing expectations from the business, the team, and users. It’s a tough job. You might feel you are doing all the right things, but your team is just not responding. If you feel you are not getting the best results from your team, or perhaps you sense they just don’t like working with you, you might benefit from improving your emotional intelligence.
Emotional Intelligence is the ability to be aware of how your thoughts, speech, and actions impact others, and then use this awareness to manage your behavior and relationships. I’ve heard it described as the “unique intersection between head and heart.” In practice, it’s a combination of using impulse control and social awareness to moderate your behavior.
The following 5 tips to increase your Emotional Intelligence are inspired from Scott Watson’s work, an emotional intelligence speaker and trainer. I hope they will complement what you are already doing well and help you create a tactical plan to improve your emotional intelligence and the emotional climate in your team. You might find that focusing on how your behavior is impacting others can change your relationships – and positively impact your career.
Continue reading “5 tips to increase Emotional Intelligence as a Product Owner”
[Disclaimer #1: Warning: strong Scrum language ahead. If you don’t speak Scrum, you can make it through this blog, but you might need to review the Scrum Guide. For example, I use the Scrum term Product Backlog Item (PBI) which can indicate any requirement in the backlog. The PBI might be in the form of a User Story, but a PBI can be non-functional requirements, technical debt, or anything the Product Owner wants in the backlog.]
- You are <anyone on the Scrum Team.> You are half-way through Sprint Planning and tasking stuff out but realize there is a major dependency that cannot be mitigated. Everything is blocked. Sprint Planning starts over with a new Goal.
- You are the Product Owner (PO). You bring your beautifully written PBIs to Sprint Planning and start planning but you can’t come to a consensus on a Sprint Goal because the Development Team keeps interrupting with things they need to do before they can build what you want.
- You are a member of the Development Team. You are ready to dig in and task stuff out, but the PO hasn’t had time to prepare. The whole team spends the day writing PBIs.
- You are the Scrum Master. You are texting all your buddies asking for a diversion phone call because this train wreck is just too painful to watch.
It needs to be said: Poor Sprint Planning leads to a heavy, bloated, wandering Sprint. A Development Team that just can’t take flight. Work gets blocked for days because the team is waiting on another team or resource to do something important – but they have their own important stuff to do. PBIs blow up, they don’t get finished, everyone is frustrated, and then there is the great rationalization to let stuff slide into the next sprint because it is “almost done.”
If the following scenarios sound familiar, this blog is for you. Continue reading “How to lose ten pounds in a Sprint”
I’m going to leave this right here: I think being a Product Owner is the most difficult roles in Scrum, and one of the least supported, which adds to the difficulty. I see so many new Product Owners struggling with the role, I started the Tampa Bay Product Owner Meetup – and if you are in the area, we’d love to have you come!
I wanted to write about a great tool I’ve borrowed from a product master, Roman Pichler. It helps with the following scenarios I often see in engagements.
- The Product Owner has an exciting new idea they want to implement, they bring it to the development team, they deliver a passionate description. The team launches right into development – but several sprints deep it feels like a struggle, and someone asks: “So – what exactly are we building – and… why? Another common question when things go awry: “Did anyone think about… (fill in the workaround, risk, issue, here…)”
- Conversely, we have experienced Product Owners who make the mistake of going too deep, designing the solution before they have clarified the ‘what’ and ‘why.’ This reduces the discovery process with the development team who could help innovate and eliminate waste long before they start writing code.
Hopefully we have all experienced the success stories too. Success comes when execution of a new product starts with the foundation of shared understanding within the whole Scrum Team. The product takes flight, development seems to fall into place, morale and creativity flow as easily as the banter in the Scrum events.
We all know these anti-patterns but how do we avoid them?
Continue reading “Product Owners: How to start with ‘Why’”
Words matter! Check out the latest addition of Scrumguides.org to freshen up your coaching language. Why? Because as coaches, trainers, evangelists and enthusiasts of Scrum, it’s up to us promote crisp Scrum practices and precise language. And “because Ken Schwaber and Jeff Sutherland developed the framework, the Scrum Guide is written by them, and they stand behind it.” [ScrumGuides.org]
- It’s not a ‘standup’ –> it’s a ‘Daily Scrum.’ Standup is actually a term from XP, it’s not part of the Scrum framework. Like writing User Stories, it’s a common practice because it helps us keep those daily Scrums short and to the point.
- It’s not a ‘ceremony’ or a ‘meeting’ –> it’s an ‘event’ and we want our Scrum Teams to honor them.
- Forgo ‘commitment’ –> emphasize ‘forecast.’ Check out this great article about why the word ‘forecast’ fits our world of collaboration and change better than ‘commitment.’
- ‘Done-Done’ is done –> ‘Done’ will do it!
- ‘Grooming’ has a very different and very negative connotation in some countries than it does in the United States –> the Scrum Guide supports using the word ‘refinement.’
- ‘Prioritize’ has given way to –> ‘Order.’ A Product Owner must make decisions to order the backlog. James Coplien’s article delves into this topic further.
- ‘User Story’ is not in the Scrum Guide –> Call anything in a backlog a Product Backlog Item (PBI.) Like refining, it’s a generally accepted Scrum practice to write PBIs in the form of a user story, but it’s not an official part of the framework.
- Define ‘Team’ –> clarify if you mean it’s the ‘Scrum Team’ or the ‘Development Team’ and help your business owners know the difference. The Development Team owns the Sprint!
- ‘QAs, BAs’ –> they are all included as ‘Developers’ The Scrum framework makes no differentiation between specialized roles on a Scrum team.
Live your truth; hone your craft; show your thanks