Agile Conference List 2020

Graduates of our workshops often ask how they can continue their journey of learning about scrum, and earn some Scrum Educational Units (SEUs). Attending conferences is a great way to accomplish these goals. Here is a list of conferences that you might consider attending in 2020. I’m sure we’ve missed some good ones, so point those out to us by leaving a comment.

Event Start Date Location Focus
Agile Open Northwest February 3 Seattle, WA Open Space
Open Leadership Symposium February 4 Tampa, FL Organizational Change
European Testing Conference February 6 Valencia, Spain Software Testing
Agile For Automotive Silicon Valley February 26 Silicon Valley, CA Automotive
Product Camp Portland March 7 Portland, OR Product Management
Agile Open San Diego March 11 San Diego, CA Open Space
ScanAgile April 1 Helsinki, Finland Agile
El Scrum Day Colombia April 3 Medellín, Colombia Scrum
Goto Chicago April 27 Chicago, IL Software Development
Regional Scrum Gathering Melbourne April 29 Melbourne, Australia Scrum
Agile Austria Conference April 29 Graz, Austria Agile
Deliver Agile 2019 April 29 Columbus, OH Agile Engineering Practices
Global Scrum Gathering New York May 11 New York, NY Scrum
Agile Maine Day May 15 Portland, ME Agile
Mile High Agile May 18 Denver, CO Agile & Lean Methods
Agile & Beyond May 19 Detroit, MI Agile
Mob Programming Conference May 30 Boston, MA Mob Programming
Agile Games New England June 1 Boston, MA Agile Games
Regional Scrum Gathering Belgrade June 4 Belgrade, Serbia Scrum
Agile + DevOps West June 7 Las Vegas, NV Agile
XP 2020 June 8 Copenhagen, Denmark Agile Software Development
Craft June 9 Budapest, Hungary Software Craftsmanship
Regional Scrum Gathering, Lagos June 15 Lagos, Nigeria Scrum
Joy Of Coding June 19 Rotterdam, Netherlands Software Development
Agile Testing Days US June 21 Chicago, IL Agile Testing
Agile On The Beach July 9 Cornwall, England Agile Product Development
ÜberConf July 14 Denver, CO Programming
System Dynamics July 19 Bergen, Norway Systems Dynamics
Agile 2020 July 20 Orlando, FL Agile
Agile Lean Europe August 19 Riga, Latvia Agile
Agile Prague September 14 Prague, Czech Republic Agile
eXperience Agile September 26 Lisbon, Portugal Agile
Global Scrum Gathering Lisbon October 19 Lisbon, Portugal Scrum
Agile + DevOps East November 8 Orlando, FL Agile
Agile Open NoCal TBD SF Bay Area, CA Open Space
Agile Open SoCal TBD Irvine, CA Open Space
AgileDC TBD Washington, DC Agile
Posted in agile, conferences, events | Leave a comment

Daily Scrum

Team holding a daily scrumThe daily scrum is the event where the development team inspects and adapts their work plan in order to make the most progress possible towards their sprint goal each day. It is one of the most misunderstood events in the scrum framework, and often implemented ineffectively. By understanding the purpose of the event, your team can realize much more value from their daily scrum.

Often, the first thing a person learns about scrum is the traditional way to run a daily scrum. They learn the three magic questions: What tasks did I get done yesterday? What tasks will I do today? What impediments am I aware of?

What people often don’t learn is why the team holds a daily scrum. If team members don’t understand the purpose, it’s very easy for the daily scrum to devolve into a meaningless status meeting, where each team member walks away wondering why they just wasted 15 minutes of their day.

The purpose of daily scrum is to allow the development team to self-organize around what work should be done today. Most scrum teams work in the complex domain. This means the team’s understanding of the work emerges and changes every day. New tasks are discovered. Some work takes longer than expected. New problems, or opportunities, emerge. In order to be effective, the team needs to inspect and adapt their work plan every day.

The daily scrum has a time box of 15 minutes. Typically, each team member shares what work they completed yesterday, and what work they believe they should contribute today. If there are any problems (impediments), those are brought to light as well. Today’s important work might be removing one of those impediments. Once every team member has shared what they believe they should contribute today, the entire team steps back and looks at the list of tasks that haven’t been picked up. They identify any work that is more important than the work currently slated for the day. Then they collectively adjust their work plan for the day, so that by the end of the daily scrum, the team is confident they are addressing the most important issues for the day.

What Else Might Happen At The Daily Scrum?

Many teams use the daily scrum as their opportunity to decide if a product backlog item(story) is done or not. This makes sense because in the daily scrum, the team is focused on the work, often called tasks or sub-tasks. If there is a product backlog item that has no remaining tasks, then implicitly the development team believes they are done. For an item to be considered done, we really want the entire team to agree. In this way, each member of the team contributes to the decision and is accountable. We want the whole team to own the done decision.

Some teams take a daily confidence vote at their daily scrum. How confident are we that we will achieve our sprint goal? How confident are we that we will complete all the product backlog items that we had committed to this sprint? A common technique for taking that poll is a fist-to-five survey.

Adding or removing product backlog items from the sprint could happen as well during the daily scrum. We do not want the business or the product owner to push scope change onto the team, but it’s perfectly acceptable for the team to pull a scope change from the product owner. For example, if it’s now clear the team will not be able to complete all the stories they originally committed to, it’s a good idea to ask the product owner which product backlog item they would like to sacrifice. The development team can refocus their efforts on the remaining items, thus increasing the chances that those will get done. Similarly, the team might realize they will complete the last of their committed product backlog items today, and there is time left in the sprint. They would ask to the product owner what they should start on next.

Conclusion

At the daily scrum, the development team will inspect and adapt for the sake of the sprint. They will adjust what work is to be done, and by whom, in order to have the best possible outcome this sprint. It supports self-organization, team ownership and accountability for delivering on their sprint goal.

Cheers,

Chris

Posted in agile, scrum, teams | Leave a comment

Don’t Change Estimates During Sprint Planning

Team estimating user storiesI encounter scrum teams changing, or worse, creating, story estimates during their sprint planning meeting. This slows down the meeting and it undermines the whole purpose of estimation: predictability.

Predictability is knowing what the business will get and when. Stakeholders might ask the team: “Can we get these features by the end of the year?” Or: “When will the new feature set be ready?”

In a sprint planning meeting, the only predictability needed is a simple yes or no. Is the story (product backlog item) in the sprint? If it’s in, then the stakeholders can expect to get it by the end of the sprint.

The purpose of estimates is to support longer-term predictability, meaning when are we going to get stories from the product backlog? This leads to the reason why we should not change estimates in sprint planning.

When we bring a story into sprint planning and break it down into tasks, we very often will discover things about that product backlog item we didn’t – and couldn’t – know before. Frequently, a team will think oh, our estimate was wrong. We should adjust it. In fact, adjusting the estimate at this time will lead to diminished predictability.

Here’s why. Breaking the story into tasks is something that has us working with the story at a level of detail greater than we have before. If we change the estimate based on what we learn by doing this work, then the estimate becomes a “corrected estimate.” All of the stories in our product backlog will have uncorrected estimates because we have not worked on those yet. If our velocity is based on “corrected estimates,” that velocity will not give a good predictability for a product backlog filled with uncorrected estimates.

Scrum teams typically work in the complex domain, which means there are always unknown unknowns. We can’t expect perfect predictability for each story, but we can achieve good predictability over time. Simply record the points for each story when the story is complete. The team’s burn up chart will fluctuate up and down, but the average rate of delivery (velocity) will give good predictability for when our stakeholders will get their stuff.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Sprint Planning

Scrum team planning a sprint.Sprint planning is the very cleverly named event (meeting) where the whole scrum team creates their plan for the sprint. The outputs from sprint planning are: the sprint goal, the forecast of which product backlog items will be delivered, and the team’s work plan.

Timing Of Sprint Planning

Sprint planning is held at the very beginning of the sprint. The time box for this meeting is two hours for a one week sprint. The Scrum Guide says the time box is eight hours for a four week sprint, though I would hope your team is not considering four week sprints. Remember, a time box is simply a limit. The meeting should never be longer than that. Ideally, you should be able to achieve the goal of sprint planning in less time than two hours if you’re doing a one week sprint.

Sprint Forecast

A goal of sprint planning is to identify a set of product backlog items that the entire scrum team has full confidence that they can deliver to the business by the end of this sprint. Each of these product backlog items is valuable to stakeholders. This list of deliverables will be shared with the stakeholders and referred to as the sprint forecast. It is the set of product backlog items that the team is predicting they will deliver to the business by the end of the sprint.

Sprint Goal

The product backlog items in the sprint should support the achievement of an overarching sprint goal. For example, if we’re a consumer website, we might have a sprint goal of streamlining the checkout process for our customers. We might have several product backlog items, each a specific enhancement to help improve or streamline the checkout process. Each has a specific deliverable that adds meaningful value on its own. Together, they support the sprint goal of streamlining the checkout process.

The sprint goal is a really powerful concept because a well-crafted sprint goal is more important than the individual product backlog items that compose it. Over the course of the sprint, if the team identifies better ways to achieve the sprint goal, it might be reasonable for them to pursue those. They may even shift or change which specific product backlog items they deliver if by doing so they can do a better job of achieving the sprint goal.

Work Plan

The outcome of the sprint from the business’s point of view is the sprint goal and the individual product backlog items that compose the sprint goal. From the point of view of the scrum team, however, there is one more very important component in the output of a sprint planning meeting: The team’s plan for what work they will do in order to achieve the sprint goal. Usually this plan is a big list of tasks. It’s worth mentioning that some tools call these sub-tasks, but I just call them tasks.

A task is an item of work, something that someone or perhaps a pair or even a whole group of people will do. For example: writing some code or doing some testing. The key difference between product backlog items and tasks is that tasks are actions while product backlog items are outcomes.

Sprint Planning Agenda

Traditionally, a sprint planning meeting has a two-phase structure. In the first phase, the team is committing to a set of product backlog items and crafting the sprint goal. In the second phase, the development team does a work planning session to identify the tasks they need to work on in order to achieve that goal.

A well-run sprint planning session will spend most time in the second phase where the team is tasking and work planning. If the team has a good definition of sprint ready, the first phase moves along quite quickly.

In the second phase of a traditional sprint planning meeting the team self-organizes to identify all of the work required for each of the product backlog items in the forecast. Don’t expect that the team can identify all of the work at this time, however. The nature of complex work is such that our understanding of what tasks will be needed is going to change as the team does the work. So in sprint planning, our task list is just a starting point.

After the team has broken the product backlog items down into tasks, they may decide there is more work than expected, and they do not have full confidence they can deliver the set of product backlog items they originally said they could. This is okay — we are still in the sprint planning meeting.

The development team presents the situation to the product owner, asking the product owner to remove product backlog items until they arrive at a set that the team has full confidence they can deliver. In this way, the whole team exits the sprint planning meeting with a sprint goal, a forecast, and a plan that they all believe will result in the achievement of the sprint goal.

Learn More

Posted in agile, scrum | Leave a comment

Role Of Managers In Large-Scale Scrum

Puzzled Manager With LeSS DiagramA client who is basing their scrum adoption on the LeSS scaling framework recently sent me the following question about the role of manager in Large-Scale Scrum.

Question

I’ve read that when scaling scrum with LeSS, cross-functional teams need to have one manager. The author advocated strongly for this, but in reality, I’ve seen this fail miserably. Losing the domain owner causes the group to skew heavily to the bias of the team manager, as well as lose the ability to strongly drive and foster domain expertise. I’ve seen product people be appointed, and the tech goes to pot. Also, I’ve seen technical people not want to report up through product. I’ve seen engineers as team managers, but it’s rare to find good engineering/product people, and you have the reverse problem. I’m not completely convinced that a team manager is a good idea. Chris, what are your thoughts?

Answer

My experience aligns with yours. I think teams work best when it is clear that their product owner is the one person who directs what objectives they focus on. The development team member’s job is to work with their teammates to build a high-quality solution to the problems/objectives selected by the product owner.

The role of manager becomes much more about coaching and mentoring, not assigning work. I’ve seen it work well when individuals have managers based on their primary skill area. For example, a Java engineer having a manager who is an even more skilled Java engineer. The manager helps the contributor to improve their skills and grow into an ever more valuable contributor. The managers also anchor communities of practice (COP), sometimes called guilds. All of the Java engineers get together on a regular basis in their COP/guild to discuss things related to Java development: tools, conventions, and architectural direction. These decisions influence how they do their work, but not what work they do. Sometimes, a COP/guild identifies a technical objective they feel is important to the business and may submit requests to specific teams’ backlogs to address the issue. In these cases the COP/guild will make the business case for why the product owner(s) should have their teams pursue the objective.

Managers also have an important role in creating and maintaining an environment where teams will thrive. This usually involves working with scrum masters to identify systemic impediments reducing teams’ effectiveness and implementing interventions to improve the environment.

All of this seems to align with the description of the manager role on the LeSS website.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Sprint Planning Prep For Product Owners

Sprinter getting readySprint planning is the first event each sprint. Doing it well will align the scrum team and set a course for success. Doing it poorly will waste time, energy, and team morale. Here’s how a product owner can prepare for a successful sprint planning meeting.

Prerequisite: Well-refined product backlog items

If your sprint planning is to have any hope of succeeding, you need to already have well-refined (some say well-groomed) items at the top of the product backlog. I recommend maintaining two to three sprints worth of sprint-ready items (stories) at the top of the product backlog.

Start With A Goal In Mind

The product owner should walk into sprint planning with a meaningful sprint goal that they would like the scrum team to achieve this sprint, and a set of product backlog items that would support achieving that sprint goal. For example, the desired sprint goal might be to reduce the time it takes for a customer to complete their order. Some of the supporting product backlog items might be: prefilling the bill info, prefilling the shipping info, and optimizing the speed of the database for the check-out transactions.

Order The Backlog To Support The Goal

Once the product owner has their proposed sprint goal identified, they move sprint-ready product backlog items that would support that goal to the top of the product backlog. The product owner can use the team’s historical velocity to guide them as to how many stories would be reasonable. If the team’s velocity is 100 points per sprint, then the product owner might select about 100 points worth of stories supporting their proposed sprint goal, and move them to the top of the product backlog.

Be Prepared For Change

All of this may sound like the product owner gets to plan the sprint without consulting the team. Nothing could be further from the truth! This pre-work that the product owner does becomes the starting point for the sprint planning meeting. In the sprint planning meeting, the product owner and development team work together to create the sprint goal and identify which specific product backlog items will be in the team’s forecast (some say commitment) for the sprint. This pre-work by the product owner will set the stage for a productive and efficient sprint planning event.

Cheers,

Chris

Posted in agile | Leave a comment

Business Value Myths

Pot of gold with rainbowTo prioritize items in a scrum team’s product backlog, the product owner needs an estimate of both value and cost for each item. This way, they can identify which items have high ROI and move them to the top of the backlog. Other concerns such as dependencies must be considered, but in general the team should always be working on the product backlog item (PBI) with the highest ROI.

This makes sense. And yet, most organizations don’t have estimates for the value of the items in their scrum teams’ product backlogs. Why this glaring omission? I believe that it is due to several common myths, or misunderstandings, about the nature of business value.

Myth: Business value is money.

Many people mistakenly think that we should/could put a dollar (or currency of choice) value on each product backlog item. It’s not that simple. Money is a one-dimensional concept; it can be represented by a single number. But business value is multi-dimensional.

The business values money in multiple forms: revenue, cost-savings, and profit. The business may also value: increasing market share, breaking into new markets, improving our brand recognition, attracting & retaining great employees, reducing technical debt, understanding emerging technologies and trends, environmental sustainability, giving back to the community. Anything that the business is willing to expend resources to pursue, is something that the business values. So you see, business value can’t be expressed in a single dimension with a single number.

Myth: Business value can be measured and quantified.

Measuring all of the dimensions of value is essentially impossible. It may be possible to measure some of the dimensions. Let’s say we have a PBI for increasing the size of the ‘Buy Now!’ button. We think that changing the size of the button will lead to more sales. We could implement the new button and run an A/B test and measure how many more sales occur. But this is only measuring one dimension of value, not total value. And, it’s a trailing metric. That is, we have to implement the PBI in order to measure the value created. We need leading metrics, or estimates, so that the product owner can make well-informed decisions about what to build.

Myth: Business value is objective.

We would like there to be an absolute, objective truth to what the business value of a PBI is, but there isn’t. We build products for our stakeholders. Value is in the eyes, and opinions, of those stakeholders. Therefore, it is inherently subjective. Different stakeholders will value the same PBI very differently. Oh, and their opinions, and thus the value, changes over time.

So here we are. Business value is multi-dimensional, can’t be measured, is subjective, and changes over time. It sounds totally intractable! No wonder people get stuck. The good news is that business value can be estimated using some simple, yet very effective techniques. Stay tuned for future posts about exactly how to go about this. If you just can’t wait, sign up for one of our Certified Scrum Product Owner (CSPO) or Advanced Certified Scrum Product Owner (A-CSPO) workshops.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Defects And Done

Question

The developers on our scrum team are done with a story (product backlog item). Then defects are found during QA testing. Do we count it done? What about the defects?

Answer

Not DoneMy general advice is that a story should not be considered done in the sprint if there are defects, or if the testing isn’t complete. If you know there is more work to do before the story would be acceptably complete then it’s not done. This is where the definition of done comes in.

A key part of scrum is the definition of done. The idea is that when a scrum team says a story is done, then the business can recognize the value anytime they choose. For software products, this means the story is ready to release. This is why a scrum team should have all of the skill areas needed to get something all the way done. This usually includes testing.

On the other hand, sometimes a defect escapes detection even when we’ve made every effort to test and confirm that the story is complete. If a story is tested, declared done, shown in the sprint review, and some time later a defect is found, that defect becomes a new product backlog item. Of course, the team may want to revise their definition of done, or at least their testing procedures, in order to prevent any similar defects in the future.

If you need help creating a good definition of done, have a look at How To Create Your Team’s Definition Of Done.

Cheers,

Chris

Posted in agile | Leave a comment

Daddy, Where Do Product Backlog Items Come From?

StorkA scrum team works from a prioritized list called the product backlog. Product backlog items are often called user stories. In this article we’ll examine the lifecycle of a product backlog item. It starts with conception. You see, when a product owner and a development team love each other very much…

What Is A Product Backlog Item?

A product backlog item (PBI) is a request. The PBI describes a valuable outcome that stakeholders want from the scrum team. When I use the word stakeholder, I’m referring to someone outside the scrum team. Example PBIs include: enhancement requests, bug fixes, and documents. In each case, there is a valuable and verifiable outcome the business wants the team to produce.

Where Do Product Backlog Items Come From?

The PBI is a request for the team to create some value. These requests can come from almost anywhere: customers, sales, marketing, managers, product management, or other teams. Members of this scrum team probably have ideas about what they should build as well. Literally anyone can make a request or suggestion.

How Do We Manage Inbound Requests?

We don’t want every request going directly into the product backlog. That would make a mess. The product owner needs to collect all requests in a holding area. I call this holding area the protobacklog. The product owner evaluates each request and refines it with stakeholders. They will solicit a business value estimate and the initial acceptance criteria. Armed with this information, the product owner decides if this request should be pursued further.

Refining Requests With The Scrum Team

For the requests that make the cut, the product owner presents them to the development team during a product backlog refinement meeting. This meeting is sometimes called storytime or the backlog grooming meeting. Typically, the product owner will invite the stakeholders who care about the request. This allows the development team to interact directly with those stakeholders and thoroughly understand their request. During the meeting, acceptance criteria are negotiated, an estimate is created, and the team indicates if the request is sprint ready. After this initial refinement with the team, the product owner decides whether to add the request to the product backlog, or not.

Welcome To The Product Backlog

Each item that makes it into the product backlog will have the following attributes: description, order, work estimate, and value estimate. The description is often divided into an overview statement and a list of acceptance criteria. The order, sometimes called priority, is simply its location in the product backlog. The product backlog is a strictly ordered list; no two items are of equal priority. The work estimate is created by the development team and is frequently expressed in story points. The business value estimate is created by the stakeholders and is often expressed in value points. If that last bit intrigues you, you might be interested in learning more about business value estimation in our Certified Scrum Product Owner and Advanced Certified Scrum Product Owner workshops.

Where Do Rejected Items Go?

It can be useful to keep requests that didn’t make it into the product backlog. We don’t want them cluttering up the protobacklog, so we put them in the icebox. The icebox is where requests go to die, or at to least wait in suspended animation. The icebox is an unmanaged list that doesn’t get any additional attention or effort. Every once in a while, something happens that makes an old request more interesting and the product owner can thaw it out and move it back to the protobacklog.

How does this compare to the way requests get into your team’s product backlog? Leave us a comment and let us know.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Emergency Work In Scrum

Red box with axe in case of emergencyScrum strikes a useful balance between flexibility and focus. In sprint planning, the product owner presents the most important objectives to the development team. The development team commits to as many of those as they believe they can deliver in the sprint. Once sprint planning is over, the business doesn’t change their mind about what they want. The development team is able to focus on delivering the product backlog items to which they committed. At the beginning of the next sprint, the business has another opportunity to change direction in any way they need to.

Every so often something comes up that can’t wait until the next sprint cycle. This could be a problem that has arisen, such as customers not being able to log in. It could be a business emergency such as needing a feature rushed into production in order to land a new client. Such unplanned work is the subject of something that I call “the emergency protocol.” The emergency protocol isn’t an official part of scrum, but it’s a useful addition that many organizations choose to adopt.

Declaring An Emergency

First off, we need one person with authority to declare something an emergency: the product owner. The product owner’s job is to make sure the team always focuses on the most valuable outcomes. Therefore the product owner decides if this urgent thing is more important than the team’s current work. Is it worth putting the sprint goal at risk?

Dealing With The Emergency

After declaring an emergency, the product owner shares the emergency with the development team. It’s important that they go to the whole team, because we want the team to take ownership of this emergency and decide how best to resolve it. Maybe the whole team will swarm on the issue. Perhaps the team will decide that two or three members can address the emergency while the rest of the team continues with the planned work. It’s important that the team decides, not somebody outside the team.

After The Emergency

After the emergency has been resolved, the team gathers together and considers whether they still have full confidence they can deliver all the sprint backlog items and achieve their sprint goal. If they believe they can, then they move forward as usual. If, however, they no longer believe they can get everything done, then the product owner decides what items to remove. If the business is not going to get all of the originally committed product backlog items, then deciding which ones should be sacrificed is a business decision we want the product owner to make. The product owner selects one or more product backlog items to remove until the team has confidence they can complete the remaining items.

How does this affect the team’s velocity?

Since the emergency was unplanned work, there are no story points associated with it. Velocity is a metric that tells us the rate at which planned work is getting done. Unplanned work reduces the rate at which the planned work gets done. That is to say it reduces velocity. Remember: story points and velocity are a tool for predictability, not a way to keep score.

Does your organization have a different way of handling emergency work? Leave a comment and let us know.

Cheers,

Chris

Posted in agile | Leave a comment