product Archive

0

Free Sprint Planning Guide and Agenda

By
Derek Huether
– July 22, 2011Posted in: Agile, Project Management

As part of an Agile assessment, I sat in on a sprint planning meeting.  Though many out there are having sprint planning meetings at the beginning of every sprint, are they getting the most out of the time and effort?  As part of the services to my client, I will be providing a free cheat sheet for sprint planning.  It is both a guide and an agenda, to help keep them focused.  If you want a copy, just click the link at the bottom of the post.

What is Sprint Planning?
The purpose of the sprint planning meeting is for the team to agree to complete a set of the top-ordered product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

Who Does It?
Sprint planning is a collaborative effort involving:

  • ScrumMaster – facilitating the meeting
  • Product Owner – clarifying the details of the product backlog items and their acceptance criteria
  • Agile Team – defining the work and effort necessary to fulfill the forecasted completion of product backlog items

Before You Begin
Before getting started we need to ensure

  • The items in the product backlog have been sized by the team and assigned a relative story point value
  • The product backlog is top-ordered to reflect the greatest needs of the Product Owner
  • There is a general understanding of the acceptance criteria for these top-ordered backlog item

Backlogs
The product backlog can address both new functionality and fixes to existing functionality. For the purpose of sprint planning, product backlog items must be small enough to be completed during the sprint and can be verified that they were implemented correctly.

Right Sizing Backlog Items
Product backlog items too large to be completed in a sprint must be split into smaller pieces. The best way to split product backlog items is by value not by process.

Plan Based on Capacity
Mature teams may use a combination of team availability and velocity to forecast what product backlog items can be finished during the sprint.  New teams may not know their velocity or it may not be stable enough to use as a basis for sprint planning.  In those cases, new teams may need to make forecasts based solely on the team’s capacity.

Determining Capacity
The capacity of a team is derived from three simple measures for each team member:

  • Number of ideal hours in the work day
  • Days in the sprint that the person will be available
  • Percentage of time the person will dedicate to this team

The Planning Steps

  1. The Product Owner describes the highest ordered product backlog item(s)
  2. The team determines and prioritizes what is necessary to complete that product backlog item(s)
  3. Team members volunteer to own the work
  4. Work owners estimate the ideal hours they need to finish their work
  5. Planning continues while the team does not exceed determined capacity

Download the free 2-page Sprint Planning Guide and Agenda

Drawings by Pictofigo

Popularity: 2%

Tags: , , , , , , , , ,
0

The Critical Path Week Ending February 28

By
Derek Huether
– February 28, 2010Posted in: Project Management

January 28 through February 5Due to working crazy off hours in preparation for my v1.0 launch, I not only forgot to do a week in review on the 20th, I also missed meeting my writing commitment on the 24th and 25th.  Whatever the excuses, I was feeling a little burned out.  I have to remember this is a marathon and not a sprint.  Writing a daily blog takes a lot of discipline.  Though I have so much to say, it can escape me if I don’t get the idea captured quickly.  Wow, it’s hard to believe it’s almost March.  At least there should be viewer posts about snow removal.

2/26/2010

Putting Things In Perspective

I had mild chest and shoulder pains this morning. I am in the ER waiting to see the doctor. I’ll let you know the outcome and my status shortly…

2/23/2010

Satisfying Needed Scope Versus Wants

There are many templates and means to ensure your project meets the requirements.  But I can’t stress enough how important it is to ensure you’re working to satisfy the requirements (or scope) first…

2/22/2010

The Hateful Cycle of Apathy Hits a Nerve

Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I’ve seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it…

2/21/2010

How To Prevent Your Project From Hemorrhaging

This post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating. Goldplating is very common in application development and can be very expensive…

2/20/2010

How Owners Managers and Leaders Differ

I was asked a very interesting question today, requiring me to stop and think. How do I believe being an entrepreneur and a business owner differ? It’s a very good question because…

2/19/2010

What You Need Is Some Kaizen

While sitting in a governance meeting the other day, I heard how (before I joined the team) a vendor brought in some high paid six sigma black belts to…

2/18/2010

How to Thank a Managed Camel

I was informed I am the winner of the very first Freedom of Speech February (FOSF) giveaway from How to Manage a Camel.  My comments last week on a blog post by Gary Holmes earned me a free copy of the Method123 Project Management Methodology (MPMM™) Professional from their partners at Method123…

2/17/2010

Creeping Ever So Closer To Closure

As my startup project is creeping ever so closer to its closure and the actual launch of the product happens, I’m feverishly completing activities late into the night.  It’s not easy working crazy hours to get this done.  My family goes to bed, I drink a pot of coffee, and get to work…

2/16/2010

Interesting PMI Perspective On Claiming PDUs

…Based on the telephone conversation I had, if you’ve worked as a PM for at least 6 months, you can claim 5 PDUs.  Otherwise, if you are able to say you spend more than 1,500 hours per calendar year in that roll, you also qualify to claim the 5 PDUs…

2/15/2010

Getting Exactly What You Want

I just wrapped up a week long logo design project at 99Designs, with an intellectual property transfer agreement.  Flash back to August 2009, when I was watching Episode 13 of This Week in Startups…

Popularity: 1%

Tags: , , , , , , , , , , , , , , , , , ,
0

How Do You Know Your Metrics Are Worth It

By
Derek Huether
– February 11, 2010Posted in: Project Management

GQM Paradigm

So you want to create some metrics.  More importantly, someone has told you that you need to create some metrics.  How do you know if you’re just making work for yourself or if you’re just putting a spin on the same old data?

Ask yourself what the goals of your project are.

In trying to determine what to measure in order to achieve those goals, I recommend using a Goal-Question-Metric (GQM) paradigm. It can actually be applied to all life-cycle products, processes, and resources. I’ve been using this process for a few years and it really helps me creat a quality metric.  The GQM paradigm is based on the theory that all measurement should be [1]goal-oriented i.e., there has to be some rationale and need for collecting measurements, rather than collecting for the sake of collecting. Each metric collected is stated in terms of the major goals of the project or program. [2] Questions are then derived from the goals and help to refine, articulate, and determine if the goals can be achieved. [3] The metrics or measurements that are collected are then used to answer the questions in a quantifiable manner.

Here is an example of the GQM in action:

Goal (use this 4-step process to shape a goal)

[1] Purpose
[2] Issue
[3] Object (process)
[4] Viewpoint

Goal 1 [1] Purpose
[2] Issue
[3] Object (process)
[4] Viewpoint		 Maintain
a maximum level of
customer satisfaction
from the Help Desk user’s viewpoint
Question 1 What is the current help desk ticket trend?
Metrics 1
Metrics 2
Metrics 3
Metrics 4		 Number of help desk tickets closed
Number of new help desk tickets
% tickets outside of the upper limit
Subjective rating of customer satisfaction
Metrics 5 Number of new help desk tickets open
Question 2 Is the help desk satisfaction improving or diminishing?
Metrics 6
Metrics 7
Metrics 8
Metrics 9		 Number of help desk calls abandoned
Number of help desk calls answered
Number of help desk calls sent to voicemail
Subjective rating of customer satisfaction

As the great Lord Kelvin once said, “If you can not measure it, you can not improve it.”

Image based on Basili, Caldiera, and Rombach “The Goal Question Metric Approach“, 1990

Popularity: 1%

Tags: , , , , , , , , , ,
0

Understanding Agile Scrum and common terms

By
Derek Huether
– March 16, 2009Posted in: General, Scrum

I’ve been in a few meetings this last week where people were mentioning Scrum terms but didn’t know what they were. It’s not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I’ve seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted “something” within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it’s important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner
The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director…  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster
The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team
A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering…)  This team traditionally sits in the same room or area.

Scrum Team
Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart
Daily progress for a Sprint over the sprint’s duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog
A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you’d find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog
A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint
A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product
An output requested by the customer.  It is a completed document, process, web page, database…  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post:
Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories…

Popularity: 1%

Tags: , , , , , , , , , , , , ,