Archive for July, 2011

2

Getting on the Agile Coach List

Almost two months ago, I left my gig advising a Federal PMO to join LitheSpeed. LitheSpeed offers premium Scrum and Agile consulting, coaching, and training services. So, what do you do when you win work? Well, you put the word out that you’re looking for qualified people! So, are you an Agile coach who would like to be considered for our current and future engagements? Complete the form and you’ll be on the list.

Don’t see the Google form? Try this link

Drawing by Pictofigo

0

Free Sprint Planning Guide and Agenda

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 Agendadownload-flashcards

Drawings by Pictofigo

4

Becoming a PMI R.E.P.

As you may know by now, I left my gig advising a Federal PMO to join LitheSpeed as a Senior Manager. LitheSpeed offers premium Agile software development training, coaching and management consulting services. My relationship with the organization actually started several years ago, when I attended ScrumMaster training to earn my certification. (You can’t be a Certified ScrumMaster through the Scrum Alliance unless you get your training from a Certified Scrum Trainer®.) Well, the world is evolving and so is LitheSpeed.

See, Certified Scrum Trainers (CSTs) play a vital role within the Scrum Alliance. They are the only ones licensed to teach Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) courses. Stringent certification requirements are imposed on CSTs to make certain that only those who are qualified to meet the commitment are entrusted to engage in this role on behalf of the Scrum Alliance.

Well, what about those out there who are members of the Project Management Institute? What about those seeking the upcoming PMI® Agile Certified Practitioner (PMI-ACP)SM certification? If you want to qualify to sit for the PMI-ACP, you will need 21 training hours in an Agile-specific curriculum. To ensure members of the PMI know LitheSpeed offers quality training that will help satisfy that requirement, we applied to and were approved to be a PMI Registered Education Provider (R.E.P.).

PMI R.E.P.

What does it take to become a PMI R.E.P.? Applicants must complete a 33-page application, which includes a strict quality review of both the trainers and the curriculum. The first class we submitted and got approved was our Certified ScrumMaster course; next will be our Certified Product Owner and PMI-ACP Prep courses. As an R.E.P., LitheSpeed has been approved by PMI to issue Professional Development Units (PDUs) through the PMI website. Our goal is to equip our trainees with tools they can apply on current and future projects, not just help them qualify to take an exam.

I know this post sound a little like a press release.  But, I have to admit, applying to become a PMI R.E.P. is no cakewalk.

If you would be interested in attending one of my upcoming public training sessions or would be interested in me providing a private training session, shoot me an email!

PMI® and the PMI® Registered Education Provider logos are registered trademarks of the Project Management Institute, Inc.
PMI-ACPSMis a service mark of the Project Management Institute, Inc.

9

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it’s probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it’s waste. But, since XP2002, have we learned our lessons?    Standish Group Study

Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.