Whilst one of our Product Owners was filling this role on the biggest project team we had, he raised these issues with his peers at the time. Some, or all, of these may be problems you are grappling with too. If so, leave a comment and tell us how you addressed these issues.
“Disclaimer: Please take everything in the spirit of ‘let’s all get better at what we do’ and ‘this is just one Product Owner’s perception (although he happens to be very insightful, unbiased, mature and perceptive….not to mention modest)’. 
1. Expectation gap
After the End-of-Iteration demo there were radically differing perceptions of how it went. The Business Stakeholder’s view was that the demo was a failure on many fronts: Poor presentation; little business value demonstrated; and, low volume of work produced for a team our size. My Product Owner’s view was that the team had done a lot of work, fought a few technical and dependency issues, and delivered a reasonable amount of output, but they did not do themselves justice in how the demo was handled. I later learned from the Scrum Master that they were expecting fallout for not meeting their points target and that probably explains the vibe in the room (read more under ‘De-scoping stories’ below). There was definitely a defensive and skulking attitude from most of the team.
Not meeting the points target is not really the issue to me. We need to produce software that demonstrates business value; that is the most important thing. We can’t sell story points…
I felt that the team did not demo the work they had done well and therefore didn’t really show the work and effort they had put in during the month. There needs to be a clear explanation of the story being demonstrated, why it is there, and what the team had to do to make it happen. The rework stories should probably not even have been demonstrated because as essential as they were, demonstrating them was completely unspectacular. Since I am at most of the Daily Scrums this does raise the question, “Who is being demonstrated to?” which brings me to the next point.
2. Who is the customer in the demo?
At present our demonstrations are organised around presenting to the Product Owner and a few other internal stakeholders. This is probably because of where we are in the project and also that we have, in the past, limited customer exposure during the software development process to beta versions and very controlled requirements-gathering workshops. As the Product Owner, I generally know what is going to be demonstrated and I should not be the prime target of the demo, just one of many. Maybe I should even demo the functionality to other stakeholders: A thought worth discussing?
3. Estimation blues
I have a real problem with estimation. The crux of the problem is that this is the closest thing to ‘democracy in action’ on a software team, but it is even more extreme than that. If it was democracy, the most votes would hold sway in allocating points. At present everyone has a veto regardless of whether they are completely ignorant or not. So, when a new member joined the team he was mature enough to know what he didn’t know, and in the estimation sessions he abstained from voting. His comment was that he would have to get more familiar with the architecture and nature of the stories before he could provide meaningful input.
There are many other members of the team who know far less than he but are only too happy to exercise their veto on almost every vote. So, it goes something like this: Everyone puts their cards down and we have mostly 3’s and a few 5’s, and then Joe Ignorant who has no coding experience puts down a 20, and Pete Proficient puts down a 2. So it comes down to Pete and Joe to debate their differences. Pete says, “We have email components, all we need to do is use them and make one method call. This will take me 20 minutes.” To which Joe responds, “I have never worked with components and I don’t know what a method call is, but it sounds like there is a lot of complexity and unknown ground there.”
Now sometimes Joe will back down and Pete will concede that not everyone can do this in 20 minutes so we will go with the majority and make this a 3-pointer. But there have been many occasions where Joe, to save face or for whatever reason, says, “No, it’s a 20-pointer and that is my final offer.” So there you go, a 3-pointer gets put on the list as a 20, taking up a third of our productive capacity and radically influencing what we can select for a sprint.
As frustrating as it is for someone with no knowledge to hold us ransom like that, it should all work out fine when we complete the story in say, one hour, proving Joe wrong and moving onto the next story; but it doesn’t seem to happen that way. We seem to let the 20-pointers become a self fulfilling prophecy; at the very least the 20 points have an unconscious influence or knock-on effect in our planning.
What matters more than the frustration this causes is that the integrity of our story points gets undermined. We have people saying, “There is no way that is a 20-pointer,” once stories are already on the task board. That is a problem because if there isn’t broad consensus there can’t be broad commitment. Suggestions:
- If we want consensus then let’s make it that rather than an unqualified veto system.
- Let people veto but they must convince others of their reasons for wanting the point allocation changed. In this way the estimation will be based on fact, not emotion and conjecture.
- What about some sort of ‘normalisation trend’ where the lowest estimate is tracked against the teams estimate.
I think that this is a symptom of broader issues: Team experience levels, and letting the right people do the right work and provide the right input to the team. (See more in ‘Team experience and efficiency’ below.)
I understand that if the whole team does not believe the stories are correctly estimated they won’t be able to commit to the work. If that is the case surely it is just as bad having an inexperienced team member swaying the whole team based on some unsubstantiated opinion as it would be for an overzealous Product Owner to dictate: “That story is definitely a 2-pointer. That’s what we are putting down.” The net effect is the same: The integrity of the estimates is shot and the system breaks down.
4. Paying for housekeeping
To what point should I feel comfortable paying for housekeeping? Things like DoFixtures seem fine because they are part of the integrated testing strategy, which is part of maintainability, which is part of the mandate for this project. Source code control issues or the implementation of a continuous build server feel a bit more like housekeeping that shouldn’t take up story points. I understand the benefit of these stories I guess, it is just that it’s surprising that they are still cropping up at this stage.
5. De-scoping stories
This is probably my biggest gripe at present. During a previous sprint the Scrum Master came to tell me that the team didn’t think it would be able to finish all the stories it had committed to. Good—early notification of progress, which I never would have got pre-Scrum. Next, the team asked me which stories would be absolutely essential to complete. Good—inspect and adapt, and give the Product Owner an opportunity to have input to ensure that the correct work is done under the circumstances. But that’s where the good ended. There was no explanation of why the points were not completed. Maybe there was in the Retrospective, but I was not made aware of this. There wasn’t a remedial action plan: “We don’t think we are going to make the stories, but here is what we are going to do to try…”
At the end of the day at least the team communicated with me, another team may simply have delivered fewer points than expected. Again, there is nothing wrong with that and I’m sure everyone put in a lot of effort, but I was left feeling like I was on the wrong end of the bargain considering:
- The team estimated the points.
- The team selected which points they thought they could do.
- The team chose the stories from those presented.
- The team didn’t complete the points
That’s OK—it’s how Scrum works and I support that—but look at it from a Product Owner’s point of view:
- I thought the estimates were too high in the first place.
- I thought the team could commit to more points.
- I thought all the stories presented would be chosen.
- I thought the team would complete all the points.
I am taking an extreme stance here to illustrate my point, yet you can see how the expectation gap starts to develop. The estimation and de-scoping feel like a one way street at the moment. In the context of our definition of a Product Owner as someone who ‘drives the team to deliver…’ I don’t feel like I have any levers left with which to drive.
What is the consequence of missing iteration goals?
6. Team experience and efficiency
I get the feeling we are producing not nearly enough valuable output in a sprint. When I look around at the number of people on the project I am staggered at how little we seem to produce. I asked how the team thought the demo had gone and one of the most experienced members said, “It felt like we completed 100 points, not only 57.” Why, what burden was he carrying? He was carrying the burden of too many inexperienced team members.
The ratio of two inexperienced developers to one experienced developer feels like it is very inefficient. The cost of this inexperience feels like a double whammy: Not only are we having slots filled by people who are at the start of a very steep learning curve, but also our experienced people spend a significant part of their time coaching and so are not producing valuable output. For example, during this sprint an experienced team member locked himself away in a meeting room for a day so he could actually get some work done. Is that how we intend to resource and staff our projects? Is that efficient?
This point is related to the right people on the project doing the right work. I often get the feeling that the newer people would appreciate the opportunity to add value in areas where they don’t feel completely incompetent. An email from an inexperienced team member was effectively saying just that. I know the whole team needs to understand how things work, but it should not be seen as demeaning that there are types of work for which inexperienced people are suited, and there are types which we should not do them the disservice of forcing them into.
Realise that this is not about how much code we write. It is about acknowledging that Scrum requires a high level of maturity in order to implement it in a meaningful way. Note, I don’t say experience, but maturity—and the right attitude. If you want to be a passenger you have no place on the team. The dead weight will be identified and dealt with by the team. At least that’s how it’s supposed to work. Yet I don’t get the feeling that the team is self managing in this regard. The Daily Scrum is fairly boring because people don’t know what they should be doing or even where they can add value next.
I really feel they should be jumping at the opportunity to speak so they may say, “Yesterday I added five new fields to the UI using the code generation tools.” That should not be viewed as grunt work; it is essential work that someone has to do. We need the team to manage who does that work (rather than making use of top down assignment techniques), but I don’t think they are necessarily doing that yet. This goes back to the point of people taking on work they are not suited or experienced to do due to the pressure of being seen to be doing something—anything—in the Daily Scrum. This is the Law of Unintended Consequences at work. Junior people should feel free to say, “I have no idea what to do next. Is there something straightforward I can work on which is low risk?”
7. Pharisees vs. disciples
Whenever people are unsure about things they default into ‘pharisee’ mode. What I mean by this is they want to make sure they do the right thing so they try to follow the letter of the law. If Scrum law says, “All team members work on the same story to the degree that this is efficient so that you can have a better chance of getting things done,” then come hell or high water, they will work on one story. The subtlety is ‘…to the degree that this is efficient’. It’s easier to measure whether or not we are all working on the same story than it is to use our insight to determine if we are being efficient or not.
We need to get to the point where we really operate on the principle that the only rule is that there are no rules. We have a job to do and must do whatever we need to in order to get it done in the best possible way and as efficiently as possible. If that means that we take a look at the ‘everyone must work on the same story’ principle and acknowledge that for all the right reasons it doesn’t work for us, then so be it. Our objective is business value not scrum compliance. We must take note that there is a very good reason the principle exists, and if we don’t stick to it closely then there is a real danger of falling into the trap it is there to prevent. But rather keep that back of mind—have the Scrum Master constantly checking that we aren’t going astray—than sacrifice common sense and efficiency by making Scrum our master (no pun intended).
PS: It has taken me a few days in bits and pieces to write this. I have just come from an estimation session which was nothing like the ‘estimation blues’ I set out above. Almost all the remedies I suggest were applied by the team. Nonetheless it is worth noting that what I have set out is still valid in that these things have happened from time to time and there is always a risk they will start to happen again.”
Some, or all, of these may be problems you are grappling with too. If so, leave a comment and tell us how you are addressing these issues.
