As soon as someone gives analytical minds a number and a way to produce that number, we naturally go to work digging into its meaning. Analysis is fine when it leads to beneficial results. Many times such research leads to wasted time at best and damaging side effects at worst. Some examples:

• Velocity was average last sprint. We know we can do better so let’s push this sprint to get +10 on that number!
• The VP says she’ll take us out to the movies if we can increase our velocity by 25% this iteration.
• Team Tiger completed 30 points last sprint and we only got 23. We need to do better than them!

Before we look at these examples further, let’s take a road trip.

Driving Velocity

I live in the Phoenix, Arizona, USA metro area. Because my wife (especially) and I enjoy a famous rodent’s home in southern California, we’ve often made the 350 mile drive to that neighboring state. We know the route fairly well.  We also know that sometimes traffic, detours or other things might interfere with our usual progress.

When we arrive at the hotel our conversations about the trip never sound like:

• We averaged about 62 miles per hour this time. We know we can do better so let’s push to get +10 on that number on the way back!
• Mom says she’ll buy us extra churros if we can bump our speed average by 25% next time we come.
• My buddy Harvey drives at 80 miles per hour on this same route and we only do around 70. We need to do better than Harvey next time!

Do you talk about velocity like that after a road trip? Why not? Because the velocity is not what we are should be delivering. Let’s read that again.

Velocity is not what we are delivering.

On a road trip we are delivering a destination by a more or less certain time. While driving, velocity is important in the moment of driving, in consideration of safety and to avoid speeding tickets. No one cares if we could have gone 78 miles per hour instead of 74 in the stretch between Tonopah and Quartzite once we are in view of an artificial Matterhorn mountain!

Velocity Used Well

The three bad examples I started with all use past velocity and even some other team’s velocity. They all center the conversation around velocity, as if customers want more and more story points! Customers want working software and everything we do should be in support of delivering working software, not velocity.

I promise, if managers ask teams to deliver velocity, they will.  Most likely by cutting quality or simply increasing the scale of work size estimates, which has little to do with delivering more product.  So use velocity as an indicator, as it is used in driving.

• The team velocity now is an indicator of how much work can be done in the next sprint.
• Velocity is an indicator of what will be included within the current series of iterations making up the release.
• Velocity highlights that something is going really well or needs improvement. The improvement doesn’t come by raising velocity, it comes by making the improvement.

Let’s revisit our statements one more time, where velocity plays a part but is not the focus.

• Velocity was average last sprint. Why didn’t our new unit-test framework give us the boost we expected?
• The VP says she’ll take us out to the movies if we can get that video feature done this iteration.
• Team Tiger delivered all their stories last sprint. We need to ask them what is working so well!

There is so much more to say about velocity and how to use it. Please keep in mind the possible negative effects when we take our eyes of the product and start seeking credit for a number. And remember to deliver working software, a product, customer value, not points!

The Questions

The original post in the group asked some hard questions about the role of the Product Owner.  Questions about this role are normal since the original Scrum definition does not go into detail about the day-to-day work of the Product Owner.  I think this is intentional as one definition of this role would not fit very many teams and enterprises.  Let me paraphrase and condense the questions:

How does the Product Owner build and maintain the Product Backlog?  How does he ensure the Sprint Backlog is ready for planning?  And, how much time should be spend doing these things?

Study the Role

To understand the power, nature and key importance of the Product Owner role, we should first understand the big picture.  Some of the best documentation about the Product Owner role comes Roman Pichler. Look around his site for some great information.  In particular, Roman produced a slide set that has helped me many times when explaining the Product Owner role to executives and teams.  Read through this set on being an effective Product Owner [PDF] for some great insight.

The process of gathering information about story content; requirements, UI, etc. can vary significantly from company to company and team to team.   Scrum does not provide direct instruction about how the Product Backlog should be assembled and maintained. Scrum mostly says that the Product Owner is in charge of the backlog.  Lets focus on the main goal for the Product Owner with regard to Sprint Planning:

• The Product Owner needs to have at well defined stories ready at the start of the meeting.
• These need to be in business value priority order.
• There needs to be enough ready to fill at least one Sprint Backlog and maybe a few more, just in case.
• These prepared stories define “What?” is to be created and how everyone will know the creation is complete.

To meet these goals, the Product Owner can use whatever method is needed to collect, document, understand and define the answer to “What?” should be created.  Some things the Product Owner might do:

Product Backlog Grooming

In Roman’s writings he emphasizes the idea of a backlog grooming section. There are others also emphasize this idea and I agree with them. Sometime during the Sprint, the Product Owner and all the team developers will spend time fleshing out the stories for the next sprint and maybe a couple more. This allows the team a forward look to help guide the current work and keeps them on the road. Most importantly, it helps the Product Owner understand the costs, risks and benefit of imminent stories.

Stakeholder Communication

The Product Owner will call meetings with the various stakeholders (Marketing, Production, Finance, etc.) to create and refine stories. The Product Owner represents these interests and people to the developers on the Scrum Team. There needs to be communication with these stakeholders often so that their interests are well represented in the stories and hence the end product. These people are not on the Scrum Team (i.e. they are “chickens”), but they are customers, so their input is vastly important.

Team Communication

Besides a formal grooming session, the Product Owner should be available at any time to talk, discuss and meet with the team or individual developers. The best communication method is face-to-face conversation. When such is done between people that regularly spend time together, misunderstanding is much less likely to happen. Specs, diagrams, drawings, etc. are great. Do them asneeded in order to create a great end product. Documents are not the primary means of communication. Face-to-face is the primary means.

Time to Prepare and Define

The amount of detail and work in all this grooming and communication should be biased toward the present and face-to-face communication.

The detail in the Backlog request as far as features, business rules, and the like, should be only as much as needed for customers, Product Owner and team to understand each other. Once they are used to talking and working together, not very much will be needed. Stories in the next sprint or two will have more of this communicated while those further down the Product Backlog will have less. No reason to spend lots of time defining things that are weeks or months away since they will change.

The Product Backlog does not contain detail design.  They should have as little design information as possible, for the moment’s need. Maximize the work not done.  Remember, the team defines the “How?” of the work, which is the design.

• If the story is in the current sprint, there will be lots of this detail as it is implemented.
• If the story is expected in the next sprint, only as much as needed to be ready for Sprint Planning. Not too much.
• If the story is expected two or more sprints out, only as much as needed to have an understood vocabulary around the story. Not very much at all.

When a Product touches several domains (Marketing, Production, Finance, etc) besides the “product” domain, resist the temptation to do Product Owner by committee.  The Product Owner needs to be the one person that the rest of the Scrum Team asks for decisions of priority and completeness of work. The Product Owner may represent many other functional customers but those customers are not members of the team. This is not to say that developers are not allowed to talk to customers, they should. But questions of story definition and priority are for the Product Owner to determine.

The definition of done is defined by the Product Owner, based on customer input. It is part of the answer to the “What?” question. It should be in the story before the Sprint Planning meeting starts.  During the Sprint Planning meeting the developers may reveal that the story is to big or to difficult or somehow not possible to accomplish as defined. This is only because the “How?” that is answered by the developers cannot meet the definition of done for some reason. Hopefully this does not happen too often and usually should be resolved in the Product Backlog Grooming and communication with the customers.

Definition of done should also include technical requirements such as “Shall pass unit tests” and “Shall be built on the official build computer before demonstration.”  These the developers should define and follow.  The Product Owner should understand the importance of high craftsmanship to the end product.

The Product Owner role should not be taken for granted.  It is a key role that each team and company must refine in their own way.  Keep learning about it all the time.  It is one focus that almost always can be improved.

I enjoy helping people with Scrum and Agile. The more I do it, the more I learn and enjoy it. Many of my recent in person and online encounters have had a similar flavor to them. I didn’t put my finger on it until this morning.

In an online exchange people have been discussing the Sprint Burndown Chart. Opinions on it’s usefulness, how it should be used and what it contains vary widely. That’s OK, because every team and situation is different. The point that struck me was one particular comment. This person described how their chart showed burn down of estimated hours for tasks. They adjusted the burndown each day if a task’s estimated hours to done changed, essentially including actual hours into the burndown.

For example, take a task that was originally estimated at two hours. The next day the developer working on the task reports slow progress.  The task is not done with four hours already spent. The developer now estimates the task will take ten hours. So the burndown chart data point would be adjusted up by six hours to include the new estimate.

This example shows the desire of this particular team to track actual hours. I suppose they wished to compare them to the original estimates to measure accuracy, though that did not come up. (There are several reasons that I don’t like such a way of doing things, but that is another discussion.)

Other examples along the theme have been

• eight hour planning meetings
• estimating an entire five month long Product Backlog all at once
• two days of wireframing before writing the story
• sprint tracking spreadsheets with more detail than a Gantt chart

So when I was thinking about the burndown of actual hours example and other practices of potential waste, the theme hit me:

Big Design Up Front (BDUF) of Scrum

It seems many people are trying to eliminate BDUF of products, with Scrum implementations that are designed big up front.

• They need to define every possible field that might be needed on a story card before they start using story cards.
• They want to track hours and sub-hour increments on tasks, allocated by a percent of the developers time against other tasks.
• They need backlog spreadsheets with date coded story ID’s, date last edited, comments by department in separate columns and priority votes from each of five stakeholders.
• They make up two page forms for recording the definition of done and how each maps to the appropriate use case record(s).

And they do all this before the first team starts the first sprint. Because, well, they’ll need the data, right?

Maybe they will need such tracking of information someday. Any one of the above might be the right thing to do at some point for a particular team or company or product. Does it make sense to design all this infrustructure up front, not knowing if it’s really needed?

BDUF Practices in Scrum

Finally, after weeks of discussion, meetings, documents and planning, they start the first sprint. And here they are with all these BDUF practices now part of their Scrum processes. Product Owners who have more clerk-work than product innovation-work. Scrum Masters who have to keep asking for actual hours worked. Burndown charts that require an instruction sheet to interpret. A project bogged down by the same stuff that was supposed to be left behind by “going Agile.”

Simple Code, Simple Scrum

The best code is simple, direct and no more complex than it has to be. The best products have a clear function and benefit to their customers. The best information is direct, focused and simply presented. The best Scrum is simple as possible. Just as it is not possible to know all the answers to creating an innovative product before starting development, it is not possible to know all the things needed for an awesome and highly productive Scrum process. Start simple, way simple, with just the basic pieces. Then, retrospective after retrospective, the team and company learns what they need, solves it in a simple way and gets back to the real business of creating a killer product.

Just go! You will learn what you need along the way, faster than you ever imagined!

A Holistic Enterprise View

The whole enterprise can be thought of as a circle.  This circle is divided into three areas of focus.  These three areas are almost never equal and will vary based on size, age and needs of the enterprise.  Yet all three are present, if sometimes neglected in turn.  The picture is like this:

Work

This is what the enterprise does, what it is paid for.  Work is the product and all the production performed to create the product, tangible or digital.  Work is the sum of the actions, the designing, writing, testing, coding, speaking, drawing, etc. that create what the customers buy.  This is the highest focus of the enterprise and rightfully so, for without this, the enterprise cannot sustain itself.

Information

This segment of the circle represents the data or artifacts either produced or needed to do the Work.  This is be source code, documentation of all types, emails, invoices, meetings, logs, procedures, accounts payable or receivable, etc.  All enterprises large or small have and produce this data which must flow efficiently for the enterprise to do well.

People

This third segment represents the people and their interactions as they do the Work.  This is management, hierarchy, social behavior, teamwork, conflict, collaboration, politics, disagreement, personality, etc.  In order to accomplish the Work, people must communicate and interact.  It is a huge, yet intangible, component of the enterprise.

Focus Areas

Each of these three areas, Work, Information and People, must function together.  Work is always there, it is the reason for existing.  When a company first starts it may be only one person or perhaps a few more.  In such a situation the Work dominates all thought and effort.  This is OK because a small group can usually move Information quickly and get along well as People.  As an enterprise grows, difficulties within the Information and People areas more significantly impact the Work.  From cultural habit, the enterprise will want to continue to focus on the Work but there must be people designated to prevent neglect in the other two areas.

• How long does it take for a developer to learn about a field problem in a product?  The answer to this question is one measure of how will the Information area is doing.
• Does a person on the low end of the hierarchy feel safe to tell his supervisor or even division manager about a problem?  This is a check on the People part of the enterprise.
• When the lab needs new equipment, how hard is it to get?  This can touch on both Information (purchasing procedures and documents, etc.) and People (asking the manger to change the budget).

Keeping these three areas balanced according to the current needs of the enterprise is the primary function of mangers.  They have the authority, position and mandate to ensure that the Work does not suffer because of neglect with the Information and the People.  A great enterprise, dare I say an Agile enterprise, makes sure the Information moves quickly to the right place at the right time and that the People are interacting in high performance!

A Holistic Team View

This discussion started with a view to the enterprise but let us conclude by boiling it down to the Agile team.  What do these three areas of focus look like when we use them to view a small working group?

• The Product Owner pushes Information flow about what the Work should be.  Features, progress, vision and direction are controlled by Information in and out of the team.
• The ScrumMaster focuses largely on the People part of the team.  He helps them resolve conflicts to create constructive outcomes.  He creates environments in and out of the team that allows for trust and truth to be visible.
• The Team of developers focus on the Work, the product and the components that make it.  With the Product Owner providing Information direction and the ScrumMaster maintaining a People friendly environment, the Work gets all the attention it needs for high quality and speedy production!

Note that each of the Agile team roles must keep the whole circle in mind and overlap, for all three areas are important.  But each role as the area on which they focus the most.

For me the point of this view is simply another way to look at enterprises and teams.  For me it brings more clarity to my roles as ScrumMaster and Agile Coach.  Us it as a tool help you think about where you are and where you can create more value for your enterprise and team!  Let me know what you think about it.  I’d love to learn more!

And real business life sets in to create disturbances in the sprint.  Let’s look at a hypothetical but realistic situation where sprint disaster can strike.

Suppose there are two teams working on two projects.  Sprint after sprint the teams productively work down their backlogs, end with demos or reviews of what is now done and plan for the next iteration.  One afternoon in the middle of a sprint the department director calls a meeting of the teams following their daily stand-up meetings.

“As you know, ‘Old Yellow’ is our bread and butter product right now.  It’s earnings fuel the new product development you are doing.  BigCorp is our largest customer using Old Yellow.  They need A Great Feature added to Old Yellow right away.  We need to keep working on the new products but if we don’t satisfy BigCorp we’ll be in deep financial trouble.  We need to pull Joe and Tom from project New Blue and Lisa, Nancy and Ashok from project Shiny Red.  They will work on A Great Feature starting tomorrow.”

There is danger here!  The director has asked to pull people off their sprint teams in the middle of the sprint.

• Team self-management takes a hit.
• The sprint plans are in shambles.
• Velocity measures for the teams, for that sprint, are devalued.
• In short, aborting two sprints to start on something else right now is a bad thing to do!

In an ideal world the company would have enough people to handle sustaining efforts so the teams doing new development can stay focused on their iteration and release plans.  But special projects that cut into new development sometimes cannot be avoided and ideal staffing is rarely available.

Let’s return to our difficult stituation.

The ScrumMasters and Product Owners react negatively to splitting their teams, as they should.  One ScrumMaster wisely speaks up, “The teams are in the middle of sprints.  Can we leave the teams to complete their current sprints?  Then we can properly plan the development of A Great Feature for BigCorp with people dedicated to the solution.  Let me draw it out for you.”

Handling a special project

The ScrumMaster continues, “Doing it this way protects the results of the current sprint.  It also provides for clear planning of both subsequent sprints and for development of A Great Feature.  The two current teams will be slower in their next sprint because they are smaller teams but they will now have a plan for that case.  And, A Great Feature will be completed sooner with a dedicated team working on it.”

Nodding, the director says, “Our relationship with BigCorp is excellent.  I’m sure we can explain to them the benefit of a short start delay so they can have a dedicated team working on the new feature.  In fact, I bet they will like that idea.  Great job, everyone!  We’ll lay some ground work so information is ready when your current sprint completes.”

Ah!  Happy endings are so nice!