Sprint Planning Isn't Hard.

Sprint Planning can be easy. 

An agile development team is like a stool with three legs: each team has a scrum master, a product owner, and the development team.  The team practices the values of the agile manifesto and the principles of agile development.  The scrum guide outlines several rituals where the team plans and prepares for work on the next sprint.  Efficiently running sprint planning can set up the team for success, and this week I want to provide some tips on making your sprint planning sessions better. 

As a product owner, it helps to follow Roman Pichler D.E.E.P. framework for a product backlog.  Stories should be detailed, estimates, emergent, and prioritized.  Sprint planning depends on correct prioritization to be successful.  The product owner arranges the backlog from highest priority to lowest.  All the bugs, stories, and spikes in the sprint should have a preference.  The team takes those stories and adds them to an upcoming sprint.  It is an ideal time for the development team to ask the product owner additional questions.  

On a high-performing team, all of the backlog stories are estimated through a process I call backlog coaching and refinement.  At this point, the team adds as many stories as necessary to keep the team busy for the sprint's timebox.  If the team uses story points, you take the team's velocity and place that number of story points into the sprint.  If you use a no-estimates approach, then add the total number of stories completed into the sprint.  Either method will work depending on the team.  

Finally, sprint planning is the meeting facilitated by the product owner.  Since the product owner is responsible for the backlog's health and what the team does next, they must explain user stories to the team and justify the work's priorities.  It is also up to the product owner to respect the social compact of agile. They must accept developers' timelines in exchange for the developers receiving the priorities of the product owner.  

The sprint planning session should be a collaborative meeting facilitated by the product owner to plan the work which needs to get done.  Once finished, the team should have all the necessary information to have a successful sprint.  It takes practice and obeying the D.E.E.P. framework for the backlog, but the team's efficiency will improve, which makes the struggle worth it.  

Until next time.   

Backlog Coaching and Refinement for Beginners

Ike knew a few things
 about planning and action.

During his retirement in the 1960s, Eisenhower talked about his leadership style and the importance of planning.  He said, "Plans are irrelevant, but planning is essential." It occurred to me the person who led the allied invasion of Europe would know a thing or two about planning and success.  The agile manifesto is very clear that teams should respond to change over following a plan.  What agilists forget is we need some form of planning to make sure we can respond to that change.  Today, we talk about backlog refinement and coaching, which is a planning session that you will find valuable.  

Three years ago, I was presenting at the Agile 2018 conference.  The best part of the experience was sitting in on other people's sessions and learning about agile from a different perspective. One of those sessions was "Transplanting the Brains of a Product Owner and Scrum Master." The presentation featured a few references to Frankenstein movies and the product owner and scrum master seeing the development project from their counterpart's perspective.  

A principal takeaway was the idea of coaching a backlog.  Just as a scrum master should coach their team to be better at what they do, a product owner should coach the backlog so the stories are easier to understand by the development team.  A backlog should tell a story about how it is delivering value to customers.  A scrum master and product owner can work together at these coaching sessions.  I like to include a member of the development team in these meetings. I have nicknamed this process backlog refinement and coaching sessions, which speeds up sprint planning because the development team is more fluent in the customer needs. 

Doing backlog refinement and coaching sessions help improve the skills of the product owner.  The product owner understands how much detail they need to include in a story.  A coaching session allows the product owner to prioritize work and enable the development team to do preliminary estimates.  Finally, refinement and coaching make the process of backlog management emergent as customer value is determined.  Communication created during the backlog's refinement and coaching will strengthen the ties between the team's particular parts: the scrum master, product owner, and development team.  

Backlog refinement and coaching allow the scrum master and product owner to trade brains to see their roles from a different perspective.  The scrum master considers the time and deadline pressure facing the product owner.  The product owner understands the juggling done by the scrum master.  

In summary, backlog refinement and coaching builds teamwork on the scrum team.  The process of having a few collaborative story writing sessions with the scrum master and members of the development team will speed up sprint planning.  Finally, backlog refinement will make the backlog more detailed, estimated, emergent, and prioritized.  Eisenhower was right; a plan is worthless but planning with backlog refinement, and coaching will make the scrum team better.  

Until next time. 

The Parking Lot in Agile

Get work done in the parking lot.

A common experience growing up in America is spending time with your teenage friends doing absolutely nothing.  We called the activity “hanging out.”  We would hang out in abandoned buildings, remote locations in the wilderness, and the basements of friends.  The only requirement was the absence of adults and plenty of free time.  For many American adolescents, the destination of choice was the parking lot of a local shopping center or strip mall.  Today, I want to discuss one of the more misunderstood places in agile - the parking lot.  

The term “parking lot” is not mentioned in the Scrum guide.  It is a practice that popped up over the last twenty years to prevent discussion in the Daily Scrum from diverting attention from the sprint goal.  In my discussion on the daily scrum, I said it was up to the scrum master to facilitate the discussion and divert the more detailed conversations into the parking lot.  

As the name parking lot implies, it is a place to host temporary discussions about topics over a finite period of time.  When you run down to the shopping center, you plan to leave your car in the lot for a short time, so you can leave quickly when you finish your shopping.  The metaphor should apply to conversations.

A parking lot discussion should be: ad-hoc, limited, and purposeful.  Parking lot discussions often pop up when there is a lack of knowledge or context.  Team members are asking how to do something, what is happening and why it is happening.  These questions can often be answered in a few minutes and by another member of the team.  Thus, questions can be answered outside the context of a formal meeting.  Parking lot conversations can be answered outside the context of a formal meeting.  

The parking lot often has a limited goal, so it should be focused on just enough information to keep work moving forward.  For instance, “where is the contract for the API, and is it strongly typed?” is a perfect parking lot discussion item.  “How are we going to make this web application sticky enough to gather all of the customer's personal information,” could drag on for days and should include more than just a brief discussion.  Finally, parking lot discussions should have a purpose.  Parking lot discussions should provide education, information, and meaning for team members; otherwise, they are wasteful.  

A parking lot, by its nature, is a transitory place.  You park, share information, and move on.  The parking lot is not a place where you should gossip, loiter, or create a general nuisance.  The business has plenty of opportunities for that kind of mischief.  So use the “parking lot” discussion to help your agile practice.  You will be glad you did.  

Until next time.

How a Daily Scrum Operates.

The scrum moves the team forward.

We are focusing on the basics of agile and scrum.  As a coach or scrum master, it is essential to cultivate habits that make them successful.  The most consistent thing a team can do is the daily scrum meeting.  It is one of those little things which can lead to massive success.  

A daily scrum satisfies three critical features of agile: inspection, adaptation, and empiricism.  The team uses the daily scrum to examine what they are doing and how close they are to meeting the sprint goal.  Based on the conversation, the team can then adapt to changing conditions.  The discussions are part of empirical thinking so everyone doing the work knows what is happening and why.  

Team members gather together in a shared space to have the daily scrum.  Since most teams are not co-located and rely on virtual meetings, it is vital to set up a consistent daily scrum environment.  Keep the forum time the same.  Use a regular background for your screen.  Turn on cameras, and everyone should be paying attention.  

Before the 2020 scrum guide, the daily scrum required everyone to answer three questions; what they did the day before, what they are working on today, and what impediments they are facing. The new scrum guide eliminates this requirement because the scrum alliance was concerned that daily scrums were turning into status meetings.  It is an adjustment, but I think it is a positive change.  The daily scrum should concentrate on one thing – the sprint goal.  Each team member should talk about how they are helping to achieve the sprint goal.  If the team accomplishes the sprint goal, they are delivering working software to the customer or client.  The daily scrum helps the team achieve the value outlined in the agile manifesto of working software over comprehensive documentation.  

Technical work is complicated, which might sidetrack the discussion.  These conversations can move to a "parking lot," which looks like the following.

Team Member #1: "I do not know how to use the contract for the restful web service for shipping addresses."

Team Member #2: "I wrote that the contract is easy to understand…"

Scrum Master: "Thanks gang, let us make that a parking lot discussion after the daily scrum."

It is then up to the two team members to meet and exchange information.  The scrum master or product owner can then follow up with them later in the day to make sure everything is moving forward.  

A daily scrum should be quick to respect the team members' time and focused on the sprint goal.  Finally, the team owns the daily scrum.  If a product owner or other member is late, it should start without them.  Starting on time and staying focused will build discipline on the team. 

Of all the rituals of agile, the daily scrum should be the most routine.  The team inspects its work.  Next, the team adapts to changing conditions.  Finally, empiricism guides all decisions.  A positive and productive daily scrum will go a long way in making the team successful.  

Until next time.