Thinking About Story Points

Another way to think of points is to realize that we mostly use them in order to get the right number of Stories into a Sprint.

Each team is going to assign Story Points uniquely. It’s a language that the team develops.

When we’re a new team, we have no idea how many Stories/Points we can complete in a sprint. We might as well just take a guess at what seems right.

After about 3 sprints, most teams start to understand their own language of Points, and they have a baseline for average points per Sprint.

Normally, that baseline slowly increases over the first dozen sprints while the team learns how to work together. Eventually, the team has its own, well understood, velocity and can do a pretty good job of estimating how many stories will be completed in the next sprint.

Are You a Smart Sponsor?

Are you a Project Sponsor? Yes, if you launch projects and are accountable for their success.

Some clues that you might not be a Smart Sponsor:

  • You wonder why your department’s projects don’t finish on time … or ever … even though everyone is working hard
  • You suspect your department has too many projects
  • You’ve noticed that most meetings are spent getting everyone on the same page instead of focusing on the work

“Problem” Team Members

One of my office neighbors asked me about how I handle “problem” team members. His examples were:

  • the team member who doesn’t provide good estimates
  • the team member who doesn’t stop talking in meetings

In each case, and I argue, in most cases, there are no problem team members. I firmly believe that most people want to do their job well. However, people are often misunderstood, or they don’t understand what they’ve been asked to do.

As project managers, we must ensure that we don’t jump to conclusions. Just because we have a clear picture of what needs to be done, that doesn’t mean that anyone else shares that understanding. We must use the tools of project management, especially the Work Breakdown Structure, the Schedule, and the Risks List, to build that shared understanding.

Here’s my take on the answer to my friend’s specific questions. First, the person who has trouble estimating has a lot of company. Few people estimate well when they start out. That’s why I’m such an advocate for time tracking. Until a person builds up a history of how it long it takes to do certain tasks, it’s very hard to develop accurate estimates. I use Liquid Planner every day, and I take advantage of its timing feature to keep track of how well my effort estimates match my actuals. Second, when dealing with someone (like myself) who talks a lot in meetings, it’s important that the meeting facilitator explicitly asks the quieter members of the team to speak. There are kind and gentle ways of telling the extrovert that you’re grateful for her comments, but that you’d like to hear from others as well.

Who is the Project Sponsor?

The project sponsor is the senior leader accountable for the project’s success. The sponsor usually has financial responsibility for the project. He is placed high enough in the organization to be able to resolve inter-department disputes. He should represent the recipients of the project’s results. For example, if the project will result in a tool to be used by the sales team, the sponsor should lead that sales department.

The sponsor creates the environment in which the project can be successful. She protects the project from priority shifts. She allocates appropriate time to the project team so they can complete the work quickly. She serves as the project’s champion.

The sponsor doesn’t manage the project nor does he do the project work. Instead, he makes it possible for the project to succeed.

For more information about the Smart Sponsors workshop, click here.

Blaming the Stakeholders

I often hear technical people say: “my customer won’t make a decision and therefore I can’t begin work.”

Our job is to make it easy for our customers and stakeholders to make decisions. Try asking them questions to figure out where they are stuck. Can you prototype an interface so that they have something to work with (or against)? Do they understand their own business rules? If not, can you help them to document the important processes?

In short, don’t just sit there waiting, take action to help both you and your customer move the project forward.

Jeff’s Rule of Email

I’m teaching a course in Managing Projects for Healthcare Administration at the Marlboro College Graduate Center. We were discussing communication and specifically email. Jeff mentioned the frustration that results whenever he sends out an email that includes more than one request, but invariably the replies only include responses to the first request — any other request is ignored. We agreed that in our busy world, the only recourse is to send multiple emails, one per request.

I use Liquid Planner to manage my To Do list and this method works well for me, since I can easily turn the email request into a task on my list. Email itself is not a good task management tool; I recommend that everyone figure out a method for converting email to action items.

Curriculum for a Consulting Project Manager 101 Class

The Project Management Institute (PMI) has many different Special Interest Groups (SIGs) in order to meet the needs of its 250,000 members. PMI has asked the question:

What should be the curriculum if we had a Consulting Project Manager 101 Class?

Here are my thoughts:

  1. The book “Flawless Consulting” by Peter Block should be a primary text. It’s not only a practical book on how to become a consultant, but also an inspiring treatise on the importance of integrity and honesty. Block’s main point is that we have to bring our entire, authentic self to our consulting. I found this to be invaluable advice when I was starting out.
  2. I’d like to see a module on “How Teaching PM makes you a better PM Consultant.” I’ve become an adjunct faculty member at a local graduate school and have been amazed at how well teaching and consulting go together. I’m able to bring real world examples to the classroom, and I have all the language and techniques of PM at the top of my brain because I’ve just been teaching those concepts to students.
  3. How about a section on “You and Your PMI Chapter”? My local Chapter is a great resource for two reasons. First, the Chapter is helping to educate our local business community about the value of project management. Second, I get to network and brainstorm with local colleagues, which helps me to stay energized and excited.
  4. Legal Issues: we all need to be kept up to date on how to develop a good contract, what kind of insurance to maintain, and how to avoid incurring liability.

What else do should be part of the curriculum?

Are team building exercises bad for introverts?

Here’s an interesting discussion from Tech Republic about the value of team building exercises.

http://blogs.techrepublic.com.com/career/?p=119

Several self-described nerds wrote in to say that they find the team building exercises that have been designed by extroverts to be truly horrific for introverts. One contributer, who calls herself Server Queen, said

I find that kind of thing very stressful, as I do almost any forced socialization. Any true introvert will find forced socialization draining. That’s the definition of an introvert; a true extrovert finds solitude draining and recharges from doing things in groups.

I’m an introvert at heart but I have forced myself to learn how do to things in extroverted ways because I find it easier to make a living using that mode of expression.

I think that team building exericises can be valuable but only if we as designers put a lot of thought into their development. The hoky “let’s all throw the koosh ball” games are perceived as a waste of time by all but the most extroverted of participants.

I love Thiagi’s games and have used several of them to good effect. But from now on, I’m going to put more thought into whether these games are safe for introverts.

Meetings are not Deliverables

When I ask my project management students to develop their first work breakdown structure, there are inevitably a few meetings listed as deliverables.

I feel strongly that a meeting itself should never be considered a deliverable. Meetings are held in order to achieve an objective. Therefore, we can list the desired outcome of the meeting as a deliverable, but not the meeting itself.

This is part of a larger problem, which is that meetings take on a life of their own. The worst offender is the “weekly status meeting,” held in dysfunctional organizations around the world. Team members come together having received no agenda and then a rambling discourse follows while they talk about what they’ve done in the recent past. With no direction and no documented goal, the meeting becomes an almost complete waste of time. It’s OK to have a regularly scheduled meeting time, but someone must own that meeting and give it a publicized purpose.

Some resources to help you to plan and hold great meetings can be found on my Amazon store page.

Writing the Work Breakdown Structure

The WBS is a mythic document in Project Management. Every text reminds us that the WBS is the foundation of the project plan. But what the heck is it? Perhaps appropriately, I’ve found a lot of mythology on this topic. So let’s talk about what it is and how to build it.

I should begin by saying that experts differ. I belong to the school of “Effective Work Breakdown Structures” as outlined by Gregory Haugen in his book of the same name. Thus, we are believers in the deliverable-oriented work breakdown structure.

Simply put, the WBS is an outline of all the major deliverables that will be produced as part of your project. The key is that we are talking about the nouns, the (mostly) tangible objects that will be created through project work. Those items about which we can say, “once we have all of these things, the project is complete.”

Most people have trouble with this concept at first. We have often been trained to think in terms of the activities, that is, the verbs, rather than the deliverables or nouns.

There are several ways to create the WBS. If you’re finding that you are focused on those verbs, then do a sticky note exercise. Write one activity each on a bunch of stickies. Then find a nice blank wall and arrange those verbs so that you can see which deliverable should result from each set of activities. This is a bottom-up approach.

Another approach is to begin at the top. Think about the largest categories of deliverables. Usually these consist of things like:

  • Research
  • Design
  • Construction
  • Documentation
  • Test
  • Project Management

Then decompose those major deliverables into one or two smaller categories. Thus, under Design, we may have both Database Design and Website Design. The goal is to keep the WBS fairly high level. I don’t like to see WBS documents which are longer than one or two pages (which is related to another topic: keep your projects small and manageable).

However, you do need to make sure that 100% of the project-related work is represented on the WBS. For example, say you forgot to list Documentation as a deliverable but you know that there will be documentation work that must be done. In that situation, the WBS would not be an accurate reflection of the work and all the future prject management documents would underestimate the resource needs of that part of the project.

One final thought: meetings are not deliverables, but that’s a topic for a future essay.