Scrum – Should a Product Owner vote in Planning Poker?

Product Owners definitely do not vote or otherwise influence the Team’s estimates during Planning Poker (unless they are also developer).

Basically, the best people to give estimates are the ones who will actually being doing the work.

The PO Fallacy

The PO Fallacy is that if the PO convince the team to give lower estimates then they can get more work done. They mean well as they are probably thinking about strategic goals, what their leaders wants or customer satisfaction. But the likely net result of compressing Story Point estimates is some or all of the following:

  • Overloaded Sprints
  • Not getting all of the Stories DONE that the Team committed to
  • Stories that do not meet the Team’s Definition of Done
  • Quality drops as Stories are rushed
  • Tech debt caused by the Team taking shortcuts to get everything completed
  • Unsustainable pace as the Team work evenings and weekends to complete the work they committed to
  • Unhappy developers
  • Staff turnover
  • Reduced velocity in the future as new team members are brought up to speed

How do PO influence estimates?

PO are often unaware of the effects of encouraging teams to compress their estimates. In this situation they might do the following:

  • Directly ask the Team to give a smaller number
  • Challenge the legitimacy of the estimation even though they lack the technical knowledge to do so
  • Challenge team members who give higher numbers during the initial rounds of estimation
  • Let the team know in advance what “has to be done”

Sometimes POs are aware that they shouldn’t be challenging the Team’s estimates so they use less direct methods.

  • Let a confederate in the team like a Scrum Master or a senior technical person know exactly what “has so be done” in the Sprint prior to the estimation session. The confederate then compresses the Team’s estimates on behalf of the PO
  • Give subconscious cues like laughing, making faces, rolling eyes when the team or a team member gives an estimate that they think is too high

What should the PO do during estimation?

Generally the safest approach is for the PO to stay silent and still and trust the team to come up with an accurate estimate.

More information

Making Great Avatars and Team Sheets

I make photo avatars for everyone I work with. Photos are great for putting on team boards showing who is working a given task or story.

What is the difference between a good avatar and a bad avatar?

Good avatar Bad avatar
harambe ca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-small
 Clearly identifiable passport style photo (no sunglasses, facing the camera, take in the last decade etc)  Not really sure who this is? Maybe the American guy in the team?
Clear name No name
Great for learning new names No idea who anyone is
Helpful for visitors to address team members by name “Um, who is this again?”
Great for showing ownership and pride Still not sure who it working on this
Big. Avatars should be big enough to be read by anyone within three meters of the Team’s Board. Someone always asks me if their avatar could be smaller. My answer is that they could, but that they wouldn’t be fit for purpose Too small
Usually only three per team member to encourage them to limit Work In Progress (WIP) Why are there so many of these? Who is doing all this work? Why is nothing getting DONE?
There’s only one Harambe Everyone wants to be Captain America (or Hulk)

Team Sheet

Once I have avatars for the whole teams I pull them all together and make them into a document that I call the Team Sheet.

  • One goes on the top of the Team’s Board.
  • One goes on the program board for Scrum of Scrums
  • The team take one with them to planning events, hackathons, anywhere they are representing as a Team
  • One goes on the front page of the deck they make for Showcase
  • Three more get printed for lamination and cutting up into avatars.

Link to avatar template in Word



Starting your backlog again – nuclear backlog grooming!

One Scrum team I took over had a backlog of over THREE THOUSAND STORIES that the business “needed to get done”. Given that the team has a velocity of about 30 stories in each iteration and their iterations were two weeks long this meant that if no new work arrived they theoretically had enough work to last them for almost four years, assuming no new stories were added.

To clean this mess up we started a brand new backlog and stopped using the old backlog.

We then worked with the current business stakeholders and the team to identify what they really needed and added those Stories to the new backlog. This worked for everyone. The business were able to identify and prioritise what they really needed. Everyone got a much better idea of the highest priority work and what was coming up in the near future. The nagging doubt that there were high priority Stories lingering somewhere in the monster backlog was removed. The team also felt less pressured and more involved in their work coming up. Planning also became much easier.

In the year I worked with this team we only ever pulled one story form the old backlog into the new backlog.

Quickly grooming large backlogs

After a period of time every backlog builds up a number of Stories that will never get done. There are many reasons for why you wouldn’t want to do a particular story in a backlog, these include (but are not limited to):

  • Business changed its mind
  • Already fixed
  • Duplicate of another better written Story
  • Incredibly low or dubious business value
  • Badly written or just forgotten what it was about
  • Change in business strategy
  • Change in legal environment
  • Change in competitive environment
  • Not technically possible
  • It was a shit story to begin with

So how do we quickly identify dead stories and remove them from the backlog?

Whole Team Grooming

One way to quickly identify dead stories in a large backlog is to set up a session with the Product Owner, Team and relevant stakeholders and get them to review the backlog collaboratively.

Prior to the session print every story in the backlog and randomly place all of the story cards on a large table. When the participants arrive ask them to group the stories into related areas and while doing that to identify any stories that are no longer needed.

Have a laptop handy so any questions about the detail of a story can be quickly looked up.

Identify High Priority Stories

Add value to a backlog review by identifying any high priority Stories as you go. Sometimes in a large backlog some high priority stories can get lost or forgotten. This will help the product owner make sure that they are planning the right work into the upcoming iterations.

Top Tips

Print Story cards if you can. JIRA and Rally both have ways to do this. If you are using another tool it might be a good idea to export it into a csv and them use mail merge to create easy to print cards for large backlogs.

Take all of the seats out of the room to encourage people to keep moving and get the job done.

Many hands make light work. Book the session at a time when everyone is available and not towards the end of a sprint.

Make it fun. Bring doughnuts. Have a prize for the person who removes the oldest story or the worst written story.


The first time we did this exercise in my current role we found that 11% of tickets were no longer needed.

The second time we did this was after a major release and we found that a massive 42% of tickers were DONE, not needed, duplicates, related to the old brand or functionality.

Should you Showcase Stories that your Team do not get DONE?

My preference is for teams to not Showcase Stories that do not get DONE.

Stories are rarely nearly DONE

In several years of Scrum I’ve lost track of the amount of times that I have heard a Team say that a Story is nearly DONE or mostly DONE, almost DONE or 99% DONE or will be DONE very quickly after Showcase and then the Team still struggle with same Story for most of the next Iteration or longer.

What I tell teams is that if I hear any word prefixing the word DONE like “nearly” or “almost” that what my coaches ears really hear is the word “NOT” eg the Stories are NOT DONE.

Teams should not take credit for work that is not DONE

One of the main points of Showcase is to congratulate the Team for the hard work they have put in to getting their Stories DONE.

If a Team knows that they can Showcase NOT DONE Stories then they won’t work on the kinds of behaviours that enable them to get the maximum amount of Stories DONE in a given Iteration.

Being honest with stakeholders builds trust

It can be highly embarrassing for the Team if stakeholders see a NOT DONE Story at a Showcase and then a few weeks later they still cannot see the feature on the live site. Explaining why the team claimed something was finished when it wasn’t is a lot more difficult than admitting a Story didn’t get DONE in the first place.

The Teams reputation is not worth risking misleading stakeholders about one Story.

Having NOT DONE Stories is incredibly wasteful 

Even if a Story is “99% DONE” it still has to go through the following process to get DONE in some future iteration.

  1. The PO must prioritise the Story again
  2. The Team must review and rewrite the story removing the parts that are not required and adding any missing detail and conditions of satisfaction
  3. If the Story is much larger than originally estimate then it may need to be split
  4. The Story must be re-estimated
  5. The Story has to be tasked out on the Team Board
  6. The Story must be coded
  7. The Story must be code reviewed
  8. The Story must be retested from scratch across all test cases on all devices and browsers
  9. The Story must be signed off
  10. Throughout the Iteration the Team must update JIRA/Rally, talk about the story at Standup and communicate with each other in a timely and effective manner to ensure it passes through the Team’s Iteration workflow.

In short, any story that does not get DONE, even stories that are “99% DONE” will still require a fair amount of work from several people in the Team in the next iteration. Teams should be aware of this and they should focus on getting the maximum number of Story Points DONE.

Why you might showcase NOT DONE Stories

One of the main points of Showcase is to inform the stakeholders on the progress of the work so that they can make good decisions about future work. Sometimes when a Story isn’t done there might be some value in showing this to the stakeholder, but if you do, make sure you are clear with them that they Story in question did not get DONE according to the teams Definition of DONE and that it will be replanned into a future Sprint if it is still a priority. Another reason to Showcase NOT DONE Stories would be to share any blockers the team have with stakeholders who may be able to help clear those blockers.

Taking people from existing Scrum teams to form a new Scrum team

I am a great believer in stable teams. I think that teams need to be doing a Scrum together to get to the performing stage of the the Bruce Tuckman model of group development (forming–storming–norming–performing).

Recently I created a new Scrum team by taking developers from two existing Scrum teams in the office.

We put a lot of work into the importance of the Team and the Team coming first so disrupting two very mature and successful Scrum teams was not undertaken lightly.


The Teams were formed to work on products that required a mix of technical skills. These products have been delivered and the new products for the foreseeable future don’t require the same mix of technical skills. To make everyone’s lives easier we split the technical skills into teams that align with the work in the future product roadmap.

What steps did we take to reduce disruption?

The whole process was made easier because the initial drive to split the teams came from within the teams. They knew that they were no longer working on the same products. They knew that there weren’t getting any mixed skill stories that required the whole team to collaborate throughout the whole sprint any more.

I emailed the entire company about the change and invited everyone to ask any questions they had.

The new team were encouraged to design their own Agile solution based on their experiences with Agile.

We use both Scrum and Kanban here. All of the members of the new team were experienced with both. The new Team chose to use Scrum because they were more comfortable with the story writing, estimation and planning processes.

The Team chose two week iterations as that is what they are used to and having a similar cadence as the existing teams made it easy to synchronise the core Scrum meetings without any conflicts .The new team also chose the timings or their Scrum meetings eg Standup, Pre-planning, Planning, Showcase and Retrospective.

Building a new team

New Board

The team identified a free wall in the office that had enough space and chose to replicate the columns of one of other teams eg To Do, In Progress, Signoff and DONE. The backlog will be in JIRA just like the other teams.

New Team Name

The decision that took the most time and generated the most heated discussion was the selection of the new team name. All of our team names are car themed so the team chose Tesla as it is fast, exciting, new technology and environmentally conscious.


Throughout the whole process, where possible, we empowered the new team to make the decisions about how they wanted to work.

Keeping Retrospectives Fresh

An average Scum team will do 26 retrospectives a year. Using your favourite retrospective method 26 times in a row can become boring and unproductive and eventually the marginal utility will decrease. It’s a good idea to trial different retrospective techniques to keep the team interested and fresh ideas coming.

These are three great resources for different activities that you can use at retrospectives.

Note that some techniques will be better than others and like all things Agile you can stop doing the ones that don’t work and do more of the ones that do work.

Parallels between coaching elite sports teams and high performing technical teams

All Blacks coaching and leadership in elite teams

This is an excellent article on successful coaching techniques for elite teams. There are a lot of parallels between elite sports teams and highly performing technical teams. Some quotes:

As Henry stated: “Better People Make Better All Blacks, came from that meeting after that Tri-nations tour in 2004… It’s evolved, and it’s pretty good now. But … you’re always gonna get better.”

What you do shouts so loudly that I can’t hear what you’re saying.’

“The best thing about the All Blacks at the moment is that players can contribute so much. Beforehand I think it was dictated to us what our days consisted of. [Being able] to contribute… makes your work a lot easier than if you are being treated like a schoolkid being dictated to”. Byron Kelleher (All Black)

Both coaches (Hendy and Smith) emphasized the importance of transferring responsibility to the players, empowering them, expecting more ownership, and expecting accountability from them for the team’s success, both on and off the field.

Peer-ownership, peer-responsibility, them running the culture, and the environment of the team was hugely important to the success of the side. Because at the end of the day they knew they were totally responsible when they got on that field… They’d been given the responsibility. …We thought that was the best way of developing a rugby side… The more confidence you can give them in leading the team, in making decisions on the field, the better they’re gonna play. Also it makes them feel good, it’s good for their self-esteem.

So a simple way to live that day-by-day is to not spoon-feed players [as a coach]. And that might be [something simple like] not handing out a daily plan every day.” Wayne Smith, All Black Coach

About every seven weeks we would try and freshen the way we were doing things. So that might mean we would review the game differently. Or we’d change the training week… At one point the coaches all changed [roles]… At the end of 2009, I became defence and counterattack coach… Graham became line-out coach. And Steve became the attack coach… Then, in 2010 we changed again… We felt that we’d stopped improving. …It was seen as pretty radical… [one journalist] said it was like shuffling the deckchairs on the Titanic. But we had a feeling it would be good for us. Wayne Smith, All Black Coach

We also focused on increasing the enjoyment.

Turning showcases into SHOWCASES


Once you have been doing Scrum for a while and the Team are comfortable with the Showcase process it’s probably time to dial up the Showcase to maximise the benefits that the Team and business get from it.

Why do we do Showcases?

It lets the business know how the Product/Team/Project/etc are progressing.

If necessary the business can use what they learn at Showcase to change the future direction.

It encourages the team to focus on getting the Stories they Committed to DONE as they know the Showcase will be a public event.

It reinforces the Scrum Values of Openness, Commitment, Courage and sometimes Sense of Humour.

Showcase allows for a celebration and recognition of the hard work of the Team.

Dialling up Showcases

So if we’re going to do Showcases for these reasons then we should do them well as we possibly can.

Get the basics right

For any Showcase to be successful you have to get the basics right. The Team should be ready to go before the booked time. If there are any AV equipment to set up they should book the venue early enough to allow for setup activities. Likewise, if they are working from a laptop, make sure that any urls are preloaded and any logins required are already completed (unless that is what you are showing). Basically they should be ready to start on time and the presentation should be as slick as possible.

The Team should know what will be covered in the Showcase before starting. This should be Showcasing every Story that got DONE in the current iteration.

Stories that are not done, or are almost done, or 99% done, should not be covered at Showcase. If the Team wanted to show these Stories at Showcase they should have gotten them DONE before the end of the Iteration. Showcase isn’t for pretty thing that we’ve been working on. It’s for showing what the Team got DONE. The only exception for this is when there is value in the business knowing about important aspects of incomplete work. If the Team decide to show work that isn’t DONE then they should be clear with the audience that the work is not DONE and why they are showing it.

Get a BIGGER venue

In one contract I moved all of my Scrum Showcases into the kitchen as it’s the largest space in our office and it has a 60 inch television. Move your Showcase into the biggest venue you have. If you don’t have a large TV then try to get a projector. In another contract I moved the Showcase to an onsite auditorium that could seat 200 people. We had eight Scrum teams from a SAFe Agile Release Train showcasing in order and out maximum audience we ever got was probably over a hundred people.


Make your showcases as public as possible. Invite every stakeholder related to the Stories that they Team are working on. Let the Team know who is invited. Speak to senior stakeholders and make sure they turn up occasionally. Not knowing if the CIO (or other important people) is going to randomly turn up will motivate the team to make sure they do a slick Showcase every time.

Top Tip: Don’t do this until the team have done a few Iterations together and know how to run a good Shocase. No need to humiliate a new team that is just learning the ropes.