How You Can Get Valuable Time Back: Part 2

This is Part 2 in a series I'm writing about how you can get time back in your day, week, month, or project.   When a team reaches a natural velocity or throughput, how can you get more out of them? They physically can't deliver any faster, given current conditions.  If we assume we have stable teams, let's focus on governance and process.  Specifically, I'm going to talk about meetings again.  Why?  We all hate meetings but we all still have them. In part 1, I wrote about a strategy to enable your email auto-responder to help manage the inbound meeting invites. In Part 2, I'm going to give you a simple strategy to start Spring Cleaning your calendar.

Spring Cleaning

If you've ever had a professional organizer come to your house for Spring cleaning, they may have employed a common strategy to weed through your crap.  It doesn't matter if you are the CEO of a Fortune 500 company or some person appearing on an episode of A&E's Hoarders. We all have too much stuff.  In this case, we're not deciding if you should keep that mountain of National Geographic magazines sitting in the corner or all of those plastic shopping bags you've been keeping when you return from the grocery story. No, we're going to inventory your meetings. Over time, we tend to accumulate meetings.  Time to take inventory and do some Spring Cleaning.

Inventory

As mentioned in the last post, some meetings have value than others. We're going to need see which meeting we need to keep, which meetings we're going to give away, and which we're going to throw away.

Remember, meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are a waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you're becoming a bottleneck in getting things done.

To start, I'm going to review every existing and new meeting request and bucket those meetings into 3 categories.

1. Non value added but it is necessary.
2. Non value added but it is NOT necessary.
3. Value added.

1. Non Value Added But Necessary

Instead of automatically accepting the next meeting request, pause and consider the meeting’s return on investment to you.

• Does the purpose of the meeting align with the company’s strategic goals and priorities?
• Are the objectives of the meeting clearly defined?
• Can the organizer explain specifically why you were invited and the value you will provide?
• Will this meeting assist you in achieving my objectives?

If the first four questions were all answered with a yes, you should still ask.

• Will anyone notice if you didn't show up?
• Is attending this meeting the highest and best use of your time right now?

If any of the first four questions were answered with a no, you should seriously consider declining the invitation. If I was Spring cleaning, this pile would be earmarked to donate.  Because we can't "donate" meetings, I would propose having someone else attend on your behalf or find some way of being informed of the meeting outcomes or action items.

2. Non Value Added But It Is NOT Necessary

Did you read that right?  This meeting not only does not provide strategic value but it's also not necessary.

If I was Spring cleaning, this pile would be earmarked for the trash.  This is like a meeting to prepare for a meeting.  Before outright refusing, try to meet the organizer part way.  What problem are they trying to solve with the meeting?  Can it be solved some other way?

To ensure everyone has a shared understand of what meetings are not NOT acceptable, I would recommend making an actual list.

Thou shalt not have meetings about putting cover sheets on TFS reports

3. Value Added

If I was Spring cleaning, this pile would be a keeper.  This is something that you want or need, as part of business process.  Release Planning, Sprint Planning, Demos... I see these as all valuable meetings.  They all require decisions.

Conclusion

Remember, every time you say yes to a meeting, you are saying no to something else.

Check out some of these templates, including Meeting Agenda/Minutes template

Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

• (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal

• (Optional) representative(s) from the Management Team – clarify the high level priorities

• (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items

• (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

• The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team

• Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research

• Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team.

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

A Lack of a Shared Understanding

Earlier this week, I facilitated a backlog refinement meeting.  In the past, the team was used to all of the requirements being completed (in advance) by the analysts. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding. We came into the meeting with everyone agreeing they were on the same page.  That was true for about 15 minutes. The more we talked, the more they realized they were looking at things from individual perspectives.

At the beginning of the meeting, we had less than 10 user stories, from an analyst's perspective. By the end of the meeting, we had a prioritized backlog with over 100 user stories at different levels of granularity.  It's not perfect and it's never done.  But, it's a start.  For the first time, developers and testers were engaged at the beginning.  At LeadingAgile, we call this the Product Owner team.  When the highest priority stories get to a "ready" state, they will be pulled into a delivery team's queue.  Until then, we need to answer some of the more complicated questions, mitigate risk, and achieve that shared understanding.

Image Source: Based on hand drawn image from Pictofigo

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