New Scrum Team Challenges

A while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want? In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you've been doing Scrum for a while. It doesn't talk about things that happen leading up to your team's first Sprint.  It doesn't talk about the complexity of scaling to the enterprise.  It's just vanilla.

I just got back from coaching a new team and I'll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That's where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don't know much.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

You're new to Scrum.  You don't have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, you're new to Scrum.  How do you know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, you're new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won't have any completed work to compare your estimates to and you won't know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.

What is Agile, anyway?

The parable

Ever heard the story about the blind men and an elephant?  In various versions of the tale, a group of blind men touch an elephant. Each man feels a different part, but only one part, such as the leg, the tail, or the trunk.  They then compare notes and learn that they are in complete disagreement.

Agile, my friends, is an elephant.

The first blind man

I just completed an initial engagement with a client, for LitheSpeed.  Some of the people I interacted with were newly minted Certified ScrumMasters, some experienced developers, and some executive management.  In the mix, I met UX designers, architects, and more functional roles than this blog post should list.  The catalyst of this post happened on the first day of the engagement.  To set the stage, the organization was very clear the team is to "do" Scrum.  Due to user stories not being quite ready, the team pushed back at Sprint Planning and refused to estimate or commit to the work to be done.  I recommended the group visualize the workflow and maturation of user stories by way of a Kanban. I've made this recommendation before and it worked out quite well.  The response from one of the newly minted ScrumMasters was, "That sounds like waterfall!"  When I corrected him, confirming that it was not a waterfall approach,  he came back with an even better response.  "Well, it's not Scrum.  If it's not Scrum, it's not Agile".

If it's not Scrum, it's not Agile

A few days ago, I read a really great post by Joel Bancroft-Connors titled A Gorilla Primer: What the heck is Agile? Maybe this question is more common than I initially thought!  What I liked about Joel's post was it exposed the fact that Agile is different for so many people.  When asked what Agile is, I tend answer the question with a question.  Are you being Agile or doing Agile?  If you are being Agile, then how?  If you are doing Agile, then how?  Before I even attempt to answer the question, I want to know your perspective.  Why?  Because as with the parable and also reality, it's going to depend on your touch points.

Go read Joel's post.  I think you'll enjoy it.  When you're done, I'm sure you'll agree that if it's not Scrum, it can still be Agile.

Image Source: Pictofigo (Go get one. They're free)

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

Zero Cost Effect

I had dinner with a colleague the other night.  I inadvertently quoted something verbatim from Dan Pink's book, Drive. My colleague said if I liked Dan Pink's work, I should read something from Dan Ariely.  So, I started on Predictably Irrational:  The Hidden Forces That Shape Our Decisions. Wow, this book is crazy!  I'm not going to go into any more details in the post other than a comparison of an experiment detailed in the book and something I've seen in the real world. In the book, the author described an experiment on 34 Halloween trick-or-treaters. As soon as the children knocked on the door, they received 3 Hershey's (each weighing about 0.16 oz.) and were asked to hold the Hershey’s they had just received in their open hand in front of them. Each child was then offered a choice between a small (1 oz.) and a large (2 oz.) Snickers bar, under a Cost Condition and under a Free Condition.  In the Free Condition, they could simply get the small 1 oz. Snickers bar (for free) without giving up anything or they could exchange 1 of their 3 Hershey's for the 1 large Snickers bar.  In the Cost Condition, the children could exchange 1 of their .16 oz. Hershey's for the small (1 oz.) Snickers bar or exchange 2 Hersheys for the large (2 oz.) Snickers bar.  They could also choose to do nothing but all of the kids chose to make an exchange.

Experiment Results

In the Free Condition, in which the small Snickers bar is free, demand for it increases substantially (relative to the Cost Condition).  The results demonstrate the attractiveness of zero cost.  People gravitate more toward options that do not require giving up anything.

Example of this on a project

At work, I've had a Product Owner (PO) who wanted to add items from the Backlog to the Sprint.  During sprint planning, the team basically added a buffer, to account for unforeseen events.  I know people are going to crucify me for this, but basically, the Product Owner always seemed to want to shift priorities of work mid-Sprint.  Rather than killing the Sprint, we added a buffer.  This would allow new work to be entertained without totally derailing the work already being completed.  Yes, we could have used Kanban and all of this could have been avoided.  But, Kanban wasn't an option.

So, what happened?  I offered the PO a deal.  I could allow him to add a certain amount of work to the Sprint for free. When I did this, he usually asked for smaller deliverables (relative to other items on the backlog that were ready to work).  But, when I said some work would have to come off the table to pay for the new work, he always went big.  He would choose larger deliverables relative to other items on the backlog that were ready to work.

All I can say is we truly are predictably irrational.

---

Yes, the links to the books are affiliate links.

Awesome Scrum Intro Video

As I was reading tweets over the weekend, I discovered an awesome video by Hamid Shojaee, Founder and CEO of Axosoft. It's an 8 minute introduction video on Scrum.  With background music sounding a bit like Block Rockin' Beats by The Chemical Brothers, this video is to the point and completely awesome.

I think this type of video is necessary to show to stakeholders, who have not had an introduction to Agile or Scrum.  In this ADD world we live in, I think we need to deliver some information in the same way we would deliver features in a Sprint.  Go for the items of highest value and deliver them in a short period of time.  Additionally, deliver the information is a way that it can stand on its own.

I remember getting 50 government people in a room with an experienced Scrum Trainer, to introduce them to Scrum.  After several hours, some still didn't grasp the basics.  If they were forced to watch this video in the first 8 minutes of the training, I bet the day would have gone a lot differently.

Understanding Agile Scrum and common terms

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