Simple Cheat Sheet to Sprint Planning Meeting

WHAT IS SPRINT PLANNING?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of 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.

WHO DOES IT?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

HOW DO WE PREPARE?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

• Assign a relative story point value
• Remove dependencies
• Create testable examples
• Define acceptance criteria
• Meets INVEST criteria

WHAT IS THE BACKLOG?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

ENSURE RIGHT SIZING BACKLOG ITEMS

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

CALCULATING A COMMITMENT

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

DETERMINING VELOCITY

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

DETERMINING CAPACITY

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

THE PLANNING STEPS

1. Remind the team of the big picture or goal
2. Discuss any new information that may impact the plan
3. Present the velocity to be used for this release
4. Confirm team capacity
5. Confirm any currently known issues and concerns and record as appropriate
6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
7. Present proposed product backlog items to consider for the sprint backlog
8. Determine the needs, sign up for work, and estimate the work owned
9. Product Owner answers clarifying questions and elaborates acceptance criteria
10. Confirm any new issues and concerns raised during meeting and record
11. Confirm any assumptions or dependencies discovered during planning and record
12. ScrumMaster calls for a group consensus on the plan
13. Team and Product Owner signal if this is the best plan they can make given what they know right now
14. Get back to work

// If your team is new to Scrum, download a copy of the Sprint Planning Cheat Sheet //

Drawings by Pictofigo

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.).

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-ACP is a service mark of the Project Management Institute, Inc.

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?     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.

Empirical or Definitive

Ever heard of the cone of uncertainty?  The cone shows the historical error at certain time periods in a tropical cyclone forecast.  What happens today and what has happened in the past is pretty much all we know.  We can certainly use all kinds of scientifically proven processes or models to try to predict the future.  But, in the end, we won't know what tomorrow will bring until tomorrow.  If you are dealing with machines, you should be able to predict upcoming events with relative certainty.  If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none. We need to assume that baselines may change significantly during a project or in life.  In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins.  You do everything you can to lay it all out, attempting to account for every possible variable.  Unfortunately, you don’t know what tomorrow will bring.  So, the further out the schedule goes, the greater the risk something is going to change.  What’s it going to be?  Is scope going to change or maybe the schedule will slip?  With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown.  Even some of the unknowns aren't even known.  Just accept it!  You’re not the Amazing Kreskin.  You can’t predict the future.  The only thing that is guaranteed is something is going to change.  So, plan for that change.  Know the goal you’re trying to reach.  Keep your eye on that goal.  Now, do what you do.  Develop, lead, manage… it doesn’t matter.  What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again.  Make some adjustments and repeat.  You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it.  You can not steer a hurricane, only plan for it.  You can not prevent change…  Can you guess what comes next?  That’s right, you plan for it.

Organizing Around Teams

Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100 percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions? In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Two, team members never seemed to have time to just focus on one thing and get it completely done.

Status quo organizes teams around projects

• Projects are initiated
• We beg, borrow and steal, looking for the right people to work the project
• We pull a few hours from here and a few hours from there
• Everyone is "fully utilized" by working on several projects at the same time
• When the project is completed, we release some portion of each person’s hours back into the pool and start again
• Endless resource-management frustration

Bring the right projects to the right teams

• Teams focus on one or two projects at a time and get them done quickly
• Management prioritizes projects and queues them up for the appropriate teams
• May need to move a few people around but hopefully not many and not constantly
• Much of the resource management problem goes away
• We also get fewer simultaneous projects, more focus, and more speed of delivery

Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.

Organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.

Transparency Allows Better Discovery

My friend and colleague Sameer Bendre and myself are currently serving as Co-Product Owners for the PMI Community of Practice (CoP) blog. Like any challenge I accept, I like to eat my own dog food.  What that means is if we're going to have a blog about Agile, we should take an agile approach to its creation.  Though I wouldn't say the following is exclusively Agile, I am listing some content from a Product Owner training deck. There will be three things I guarantee: Transparency, Inspection, Adaptation

Transparency -Honesty about progress & problems Inspection - Feedback will come from real customers & users Adaptation - Tweaking of blog based on feedback & goals

Because we're initiating a project, Sameer and I are going through some discovery.  First up is project orientation.   We're doing process analysis, we're understanding scope and objectives, and we're creating the initial product backlog.

But, are we ready to start blogging?   To do so, we need to ask ourselves Why, What, and How.

Why?

What are the stakeholders’ goals?

What?

What is the Outcome Vision?  What is the end result?

How?

What is the Implementation strategy?

Yesterday I heard an awesome quote, as I sat in on a Product Owner class.  My colleague Arlen Bankston quoted Peter Skillman.

Enlightened trial-and-error succeeds over the planning of the lone genius

I've never been one to silence that inner voice.  If I have a problem, I share it and have faith in the collective minds of my readers to propose a solution.  I'm not saying I don't have vision.  I do.  What I'm talking about here is an impediment or a problem.  When I looked at the web address of the Agile CoP blog, I noticed that it was deep in the PMI website.  There was no link from the homepage.  The Agile CoP blog can only be viewed by (logged in) PMI members.  So, the question I have to the CoP members is, how do we get the word out?  How do we blog about things that others (outside of our immediate group) will actually read?

My short term solution is to repost here, on the Critical Path blog.  The next thing I would propose is someone convince PMI to allow more people to post on the Voices blog.  It's the only PMI blog that appears to be open to the world.  If PMI wants Agile readers, they need to open the blogs to more readers.

In closing, I'm not lambasting PMI.  I'm bringing attention to both an issue and an opportunity.  I want more visibility to what our CoP has to say.  I want to have our voices be heard.

HT: Pictofigo for the drawing

C-3P0 Timebox

My family and I recently went to Walt Disney World’s Magic Kingdom and Hollywood Studios. My wife was extra excited because it was going to be "Star Wars" weekend at Hollywood Studios while we were there. Imagine parades filled with Star Wars characters, Storm Troopers and Clone Troopers everywhere...and the force being with us (or maybe not). My wife was very excited when she found out she had a chance to get a picture taken with and get an autograph from Anthony Daniels of C-3PO fame. This is how it was to go down. When the park opened, a predefined amount of tickets would be given to those people standing in a line. Once those tickets were gone, there were 30 remaining "standby" tickets. There would be two autograph sessions, lasting one hour each. IF Mr. Daniels got through the "guaranteed" group of ticket holders in less than one hour, he would then start to greet the standby ticket holders in the order in which they arrived that morning. We were standby ticket holders #19, #20, and #21 (out of 30). Everyone was required to stand outside in the sun until their ticket number was called. They were then allowed into an air conditioned building to meet C-3PO. When they were done, the "beaming" fan exited the building.

Well, the morning session (in close to 90 degree heat) came and went. The first 10 or so standby ticket holders did get in. We were told to return in the afternoon. Upon returning in the afternoon, the guaranteed group came and went and as we watched the clock tick closer and closer to the one hour mark, they accepted standby after standby. We had convinced ourselves that certainly Mr. Daniels would understand that there were only a few people left in line and would stay the extra 5-10 minutes it would take to greet us and sign a quick autograph. Unfortunately, after #17, a representative walked outside and told us that Mr. Daniels had to leave for another scheduled engagement.

At first, I was pretty pissed. Seriously? He couldn't accept just a few more people and get through 100% off ALL of the people standing in line? No, later I thought about it. He had a timebox. He had exactly two one-hour sessions. He was going to get through as many autographs as he could but he still had to leave after one hour, regardless. He agreed to sign a specific amount of autographs and he met that commitment... and he exceeded it.

Have you had that situation happen to you as either a ScrumMaster, Project Manager, or Stakeholder? As a stakeholder you feel ripped off because someone else got something delivered and you didn't. As a ScrumMaster, you have to allow the team to commit to do the work. You can't force work upon them. As a Project Manager, you have to explain to everyone that if you let the time constraint slip, you would be asked to do that every time there was a commitment. You've heard it before. Please, just one more thing. Please, just one more day.

Mr. Daniels, you did the right thing. You kept your commitment. If that gig as protocol droid doesn't work out for you, I'd hire you.

Niko-Niko Calendar

niko-niko

While I was at the recent Agile Leadership Network (ALN) event earlier this month, Dave Nicolette presented a talk on metrics.  I'll admit, I'm fascinated by metrics.  I remember working on the NIH Executive Dashboard and then the NCI Dashboard between 2004 and 2007 .  But since then, I've grown to look at metrics differently.  Though I've taken steps to ask myself questions to ensure my metrics are worth something,  I've seen the Hawthorne Effect in action and it made me question how metrics can be easily manipulated. Don't you hate it when you're trying to measure team performance and then they start acting all crazy due to upcoming dates like the end of the sprint or the end of a deployment cycle?  I've seen developers start to rush.  Risk goes up and quality can go down, just to try and maintain a velocity.  Well, Dave showed a slide in his metrics presentation that really hit home for me.  It's called the Niko-Niko (mood) Calendar. Let's say your position in the company is to ensure customer satisfaction.  A useful unit of measure would be NPS (Net Promoter Score).  Think of it as a customer satisfaction or “happiness” metric.  NPS is based on the fundamental perspective that every company’s customers can be divided into three categories: Detractors, Passives, and Promoters. By asking one simple question — How likely are you to recommend [Company X] to a colleague or friend? — you can track these groups and get a clear measure of company performance through its customers’ eyes.  I've written about it before in a post titled Outdated Success Criteria.

That's all fine and good but what if your position in the company is to ensure employee satisfaction?  As a manager or a leader you should be working to keep your employees happy.  How would you measure their happiness?  You could use a Niko-Niko calendar.  Each individual on a team should identify their daily mood in one of three ways: happy, indifferent, or unhappy.  Because I keep a daily journal of what I do, I recreated a calendar to see if there were any trends.  Do you see any?  Can you see the the days I was working at my other job and I was dreading a particular meeting?  Can you see the days I spoke to LitheSpeed or when I was hired by LitheSpeed?  Though you can't make everyone on your team happy, as a manager or servant-leader, you should be creating an environment that will, in the end, make them happier and more productive.  If everyone on the team maintained a mood calendar, a manager or leader could take action before negative feelings become caustic to a team.