David Hawks, Author at Agile Velocity

Blog

Agile “Resource” Allocation: Forming Agile Teams

By: David Hawks | Dec 13, 2017 | Team, Video

In traditional resource allocation, we assign programmers or “resources” to a project based on need or availability. However, issues arise when we start working on multiple projects and suddenly our programmers are now working on multiple projects and teams. Traditional resource allocation is a sure way to overwhelm individuals.

In Agile, we form teams much differently. Agile teams work together to tackle the work that is prioritized the highest, according to stakeholders.

Learn more about forming successful Agile teams and how to prioritize projects effectively with this video from David Hawks.

Want to know more about forming strong Agile teams? Check out our whitepaper: Build High Performing Teams Through Trust and Alignment.

Video Transcription (has been slightly edited for brevity and clarity):

Traditional Resource Allocation

Hi, I’m David Hawks from Agile Velocity. Today I’d like to talk to you about Agile Resource Allocation, or people. Let’s compare how we’ve traditionally done it versus how we want to do it now. What we’ve traditionally done, is we’ve got project 1 and who do we need for that? I’ve got Alex, I need Alex for this, I’ll assign part of it to Alex. I also have Janet, I need to assign some work to Janet and we also have Camryn. All of project 1, we say, Alex, Janet, and Camryn need to get this done. Then comes project 2. Who do we need for project 2? We need Alex and Carter and Will. And then we get project #3, another project comes in and who do we need on that? We need Alex, a little bit of Camryn and we also need some help from Carter. Does anybody see a problem with this situation? We have a little bit of a problem with Alex. Alex is feeling overloaded—maybe important, maybe asking for a raise, or dusting off her resume and looking for her next gig. All of these are not good situations.

What do we do? We go to management and we say,”What are the priorities of these projects?” And they are all high priority, they all need to get done and have been committed by certain dates. So Alex has been given all these things—Projects 1,2 and 3 have to get done. She has three things on her plate. How does Alex decide to prioritize her work?

There are three main ways developers prioritize their work if left to their own devices:

Work on the coolest feature—whichever is most interesting or will help their resume
Work on the easiest one and get it off of their plate. What can I do to get this thing done and knock it out?
Whoever is screaming the loudest—which project manager they like the most, whoever buys them beer or cookies, the one who yells at them or trying to get them to work on this. This person yells at me, so I’m going to do theirs’ first.

These are not great prioritization techniques. These are actually really bad prioritization techniques and we don’t want to do those. But that’s what we’ve left our developers up to. Because you leaders are not making priority decisions, you’ve left prioritization up to the person furthest removed from understanding the business priority. And they’re going to prioritize your company based on coolest, easiest and whoever is screaming the loudest. That’s a terrible way to prioritize work.

Agile Teams Resource Allocation

What do we do in Agile? We want to form a team of people. Let’s form a cross-functional team that has all of the people that we need. We’ll call it our scrum team, kanban team or agile team. We’re going to take all these people and put them on a team together. Then we’ll build a funnel of work in front of this team. We need to prioritize this work. We won’t just assign all this work out to these developers over here, we’ll tell business stakeholders to prioritize. The problem is we can’t prioritize project 1 against project 2 against project 3 because they are so large. Project 1 might take 6 months to get all of it done and we need to make some progress on project 2.

We break down project 1 into little pieces. Then take Project 2 and break it down, then prioritize those pieces amongst the other parts of project 1. Then we’ll take project 3, and prioritize that against the other projects pieces. Now, we’ve given our team a backlog that’s ordered by our product owner and scrum. We have to make some hard choices as a business. We’ve got to decide which of these things are going to go before the other things. And instead of assigning the people to the work, we’re now going to assign the work to a team of people and then the team will work together to figure out how they’re going to divide and conquer. “Alex is overburdened, so Will needs to go and figure out how to help Alex.” Because now it’s a team goal and we’re trying to get a shared ownership of the goal together. Instead of assigning the people, we’re now pulling work into our Sprint and the team is swarming to get things done together.

Blog

Agile Team Structure

By: David Hawks | | Team, Video

In the past, we’ve used component teams in development: teams of people that with generally the same skills. These teams are typically assigned a part of a project to work on.

Bringing these different teams together to create the final product can be a hassle and can result in unnecessary dependency management, overwhelming overhead, and a longer process. Learn how to build Agile teams that are cross-functional and are optimized for an outcome as opposed to output.

Want to know more about forming strong Agile teams? Check out our whitepaper: Build High Performing Agile Teams Through Trust and Alignment

Video Transcription (has been slightly edited for brevity and clarity):

Traditional Horizontal Team Structure

My name is David Hawks with Agile Velocity. And today I’d like to talk to you about agile team structure. I believe that many teams out there are actually struggling to achieve the benefits of agile because their teams are not optimized for delivering value. Here’s what I mean by that: As organizations have scaled, we have created teams horizontally called component teams. These teams are focused on the UI layer, or teams that are focused on the middle tier layer, or teams focused on the backend database layer. When we have teams structured this way, when we get a requirement, one of two things come into play:

The UI team reads the document and figures out what they need, more than likely they’ll need something from the middle tier team. When they go to make this request, that team has a queue of work they have to wait in. And then when the middle tier team goes to work on it, they probably need something from the database team. The database team also has a queue of work and eventually they deliver something back up to the middle tier and the middle tier delivers something back up to the UI team and eventually, we get something delivered. Hopefully, we don’t loop around in this process where UI says it wasn’t exactly what they needed and they have to go back to the middle tier and the middle tier says we need something else from the database. All along our customer has been waiting for this feature. Do you think the customer is happy with this process? No. It’s lengthy, it takes a long time. The reason why is because there’s a lot of handoffs, there’s a lot of dependency management, there’s overhead in the organization of all the people trying to manage these dependencies. It gets really complex. It takes a long time. It’s error-prone and it doesn’t lead to having the best product possible.
Another challenge—each team reads the document, it says we need a shape. The UI team knows what a shape is (triangle), the middle tier team knows what a shape is (circle) and the Database teams say we know what a shape is (cylinder). Everybody goes along and works on the project until the end when they try to integrate these pieces. Do you think this goes smoothly? No, not at all. Everyone thinks the project is green and we get to the end and all of a sudden, we go red. We’re banging our heads against the wall because everything didn’t align in terms of our understanding and we find out too late.

So we try to do things where we’re integrating more often, trying to share when having this type of structure. But this structure is focused and optimized for output purposes. It’s optimized to deliver as much UI code and have resources that are working together. So when we think of scenario 1, when we were delivering this thing and the DB team down here, how well do you think the DB team actually understood the business requirements? Probably not at all, but they’re building the best database architecture. Their focus is the output of database code. Or the middle tier team is focused on the output of the middle-tier code.

Agile Vertical Team Structure

We really should be focused on as an organization is not just output, but achieving outcomes. We’re trying to deliver as much value as possible. And in the structure of horizontal teams, we’re not optimized for delivering value, we’re just optimized for delivering stuff. There’s a scary stat in our industry that says 64% of the stuff we deliver is rarely or never used. we’re delivering a lot of the wrong stuff. We’re optimizing for the wrong thing. What agile argues for is cross-functional feature teams, to form teams vertically, that cut through all the layers of the cake. We want to deliver value every sprint. That means we have to break our work down in ways, instead of creating a user story that says “build the database tables of the shopping cart” what we really want is to build a little bit of the shopping cart, “add items to the shopping cart”. A later sprint will deliver “remove items from the shopping cart”.

What we’re focused on is organizing our teams this way—we have this acronym called INVEST part of which stands for independent, valuable and testable. We want user stories and the things teams are working on to be independent, valuable and testable— they have user value, each thing is testable from a user perspective. Building the database tables for the shopping cart wasn’t testable. We could verify it meets the design specs, but we can’t verify it actually solves the user’s problem until we have integrated with these other pieces from the UI and middle tier. It’s not independent, they’re highly dependent on each other. Agile puts people together on the same team that have these dependencies so the people are close together and getting things done. We’re simplifying the communication path by putting the dependent parties on the same team. The verticle teams need to coordinate every day all day. The database people might be on different teams, and they might still need to coordinate, but not all day, every day. We may create a community of practice, for those database folks to continue to stay in sync; we don’t want to end up with 5 different database architectures, but we can do that with less often communication where we want to organize teams focused on outcome and focused on value delivery.

Blog

Don’t Let Your Agile Sprint Become a Mini-Waterfall Project

By: David Hawks | | Scrum, Team, Video

Scrum sprints can be tricky. Agile teams often fall into the trap of turning their Scrum sprint into a mini-waterfall. In other words, they take on work and save testing until the end of a Sprint, which tends to create more carryover than truly done work. Learn how to combat the mini-waterfall pitfall and save your Scrum sprint by swarming as a team, breaking work down, and tasking effectively.

David Hawks lays out his tips and tricks on escaping the mini-waterfall and achieving “Done Done” as a team in this video. Read more about mini-waterfall warning signs with our article, Your Sprint May Be A Mini Waterfall If… (https://agilevelocity.com/scrum/sprin…)

Video Transcription (has been slightly edited for brevity and clarity):

Mini-Waterfall, A Common Problem

Hi, my name is David Hawks with Agile Velocity, and today I want to talk to you about a common problem that we see with Scrum teams. The notion is that we don’t want our sprints to be a mini-waterfall. And we see this a lot. Let’s say we had a team that was 4 developers and 2 testers. We planned a sprint and pulled 4 user stories into our sprint. We’re doing a 2-week sprint and over that 2 weeks, we’re trying to get these 4 user stories done. The common trap that teams fall into is they have user story1, user story2, user story3 and user story4—what’s the most efficient way to assign this work? They say, “we’ll assign developer 1 to take the first story. Then developer 2 will take the 2nd story and developer 3 will take this story.” Developers kinda like this because developers don’t really like people—kidding—but developers like to go off and work and knock something out and put on their headphones and get something done. It’s kinda nice to be able to say, “I’m gonna go work on this, they’re gonna go work on that. I’m not going to be interrupted for eight days. At the end of the 8 days, I’m going to throw it over the wall to my QA person. QA 1 will take 1st two stories and QA 2 will take the 2nd two stories.”

How do you think this will end up at the end of this sprint? QA starts working on this and finding bugs and gets to the end. What are the chances this will carry over and not get everything “done done”? Will we have all the bugs addressed in this sprint? There’s a high likelihood that we will end up carrying over some of this stuff. If we look at a burndown chart for this sprint of stories complete, it would be flat until the very end and maybe we get something signed off and maybe we have a gap of not getting everything done. So while this is better than working on something for 3-4 months, the idea here is that we are shrinking it into two weeks which is better, but this isn’t how we want to work.

How to Avoid the Mini-Waterfall Trap

This isn’t what we want teams to do. We want to get teams out of their silos and into more swarming. In order to swarm, we have to break down into smaller chunks. We might want to break User Story1 into UserStory 1A, IB and IC and figure out as a team how to task this out into small parts where developer 1 and 2 work on that. How can we get testing involved earlier? Maybe it’s automated testing? What can we do to get it done earlier so that we can get something signed off earlier in the sprint not waiting for the last day? Which means we might have a swarming with developers 3 and 4 and QA 2 on something and trying to get it done. The question we’re challenging our teams with is what would it take to get something singed off by like day 3 or day 4? Then we’re going to continue to work on smaller things along the way but we’re swarming. We’re trying to get as many people to get user story 1 as a whole signed off, how can we do that? In our burndown chart, we’re seeing a little bit better progression throughout our sprint and reduces our risk of finding everything late and running out of time and gives us better predictability throughout our sprint. it also reduces the risk that the highest value item will carry over and reduces the risk of carry over all together.

That’s the challenge that we’re trying to push our teams to: How do you get out of a mini-waterfall? The skills here are how to break work down, how do we task and how do we swarm? Hopefully this will help you become more successful with scrum.

Blog

The Tug-of-War Between Releasing Early And Completing The Project

By: David Hawks | Dec 11, 2017 | Article, Leadership

Spoiler Alert: Your Company Could Be Losing Millions

For technology companies, the idea to “release early and release often” is not new and the ability to ship product or product increments in a predictable and accelerated manner is core to Agile. Yet, companies shy away from doing so for two reasons: they can’t or they won’t.

Necessary Feature Or Gold Plating

Longer projects means more opportunity for scope creep, and identifying when a project is complete is actually harder than one would think. When Geneca surveyed almost 600 IT and business executives, the organization found that 77% say there is lack of agreement on when a project is done, a prime symptom of fuzzy requirements and/or lack of business objectives.

The trick for stakeholders and managers is understanding whether that extra feature will actually add value to customers or if it’s just an example of gold plating. Is this extra feature worthy of delaying the release–is it something the customer wants or will it just be one of the 64% of features that are rarely or never used per Standish report?

Even worse, forget having a bad quarter. According to white paper Delivering Large-Scale IT Projects On Time, On Budget, and On Value by McKinsey & Company, the failure of large IT projects, costing $15M+, can actually threaten the life of a company. And some of the biggest contributors to large IT project failures include shifting requirements and lack of business focus.

Accelerated Release Is The Opposite Of Risky Business

There’s this thing we talk about called the “Risk Iceberg.” The risk iceberg is a way to visualize the unseen troublespots inherently caused when product development is worked in phases stacked one right after another: plan, build, test, release. With the traditional method (or Waterfall) a team could use 80 percent of the allotted time and resources by the time they discover a defect. Worse yet, the product could get in the hands of users only to discover they built the wrong product.

Agile breaks up a big project into smaller prioritized chunks of work, known as product increments. These bits are separately planned, built, tested, and deployed, in other words, 100% complete, before the team moves onto the next piece of work. A collection of chunks can become PSPIs, Potentially Shippable Product Increments, that can be tested by actual users. The cycle of build, deploy, and learn means a couple of things:

Teams and stakeholders know exactly how much work is left (no major schedule surprises)
Teams and stakeholders know how users are reacting to the product (no major market surprises)

Accelerated Release, Accelerated ROI

The accelerated release of products means teams can learn from users but it can also mean organizations will start to recoup some of the original investment or even make a profit ahead of schedule. Consider scenario A and scenario B:

Organization A is investing 100K a month for the next 12 months with a 3x annualized return. At the end of the project, the organization has spent $1,000,000. Since organization A is using waterfall, the product deploys at month 13. Assuming the original requirements are correct and the product is accepted, the organization breaks even at 16 months.

Organization B is also investing 100K a month for the next 12 months on a product with a 3x annualized return. However, organization B is using Agile.

At month two, organization B begins to deliver a percentage of product value. Value is delivered incrementally over the next 10 months. The product is complete at month 12.

Organization B becomes profitable at month 9, 5 months before organization A.

Releasing early means the ability to get market feedback, which accelerates learning, which creates a better product. Stakeholders and managers can trim the tail and end the project early if it has been determined that it is good enough. It can also mean being ahead of schedule from a profit perspective. It can also mean saving resources for another project if data shows the current one will or will not pan out. All are much better options than a blown scope or a failed product.

Blog

An Overview of the Scrum Framework

By: David Hawks | Dec 07, 2017 | Scrum, Video

This video breaks down the basics of one of the most popular Agile frameworks, Scrum, and covers topics like:

Scrum Roles
Scrum teams
Backlog Prioritization
Scrum ceremonies
Sprint cycles

See below for the full transcription.

Video Transcription

Hi, I’m David Hawks with Agile Velocity. Today, I’d like to give you an overview of the Scrum Framework.

Scrum Roles

In Scrum, there are three basic roles: the Product Owner, the ScrumMaster, and Development Team.

The Product Owner is responsible for the vision of a product and for turning said vision into an ordered list of items for the Development Team—or Dev Team— to work on. Their job is to create clarity for the team and to act as a conduit between the Dev Team and the customer. The ScrumMaster’s job is to facilitate the Scrum process and to help the team improve. The Dev Team is made up of all the people required to get the product built and to the customer.

Prioritizing Our Work

In Scrum, we start off with something called the Product Backlog, which the Product Owner is responsible for maintaining. Anyone can contribute and feed items into the backlog, but the Product Owner manages and orders this list. We say order, as opposed to prioritize, because we don’t want the items in the backlog to all be marked as high priority by senior management. We want them in a specific order from most important to least important.

Scrum Events and Cycles

Now, the first event in Scrum is called Sprint Planning. In Sprint Planning, the Dev Team is meeting with the Product Owner and pulling in items from the Product Backlog and into the Sprint Backlog—the list of items the team plans to work on during that specific Sprint. Notice I use the term “pull”, meaning the team selects the work they will do in a Sprint based on the order of items in the Product Backlog. The team then breaks down these items into tasks, typically no bigger than a day’s worth of work. The goal of Sprint Planning is to answer the questions “What are we going to work on, and how are we going to do it?” It’s also important for the team to have a shared goal and a shared commitment to this goal before beginning their Sprint.

Once we begin a Sprint, we have what we call a Daily Scrum every day. The Daily Scrum is where the Dev Team syncs up on the plan that they created during Sprint Planning. This is also when the team pulls in tasks for the day, discusses any blockers they might have, and creates visibility around the work that everyone is doing in the Sprint.

At the end of the Sprint, the goal is to have a Potentially Shippable Product Increment (PSPI). We’re trying to get something of incremental value done every Sprint. This doesn’t necessarily mean that we’re shipping every two weeks, but the product or part of the product created is valuable enough that it could ship if need be.

The next step is to get feedback on the thing that we built during our Sprint. We make sure that we’re headed on the right path and see if there’s anything we need to adapt to better fit the user’s needs.This feedback will then become items that will be looped back into the Product Backlog, where it can be ordered and pulled in by the team in a future Sprint.

The last Scrum Event is the Sprint Retrospective. This is where the Scrum Team (Product Owner, ScrumMaster, and Dev Team) meets to reflect on their previous Sprint and to figure out how to improve as a team. Retrospectives typically last 90 minutes and are there to help us incorporate continuous improvement into our team culture and into our Sprint cadence.

So, that’s the complete Sprint process! The next day, it’s time to kick off the next Sprint with Sprint Planning and repeat the cycle.

So that, in it’s simplest form, is the Scrum Framework. Thank you.

Blog

Agile Risk Management

By: David Hawks | Nov 30, 2017 | Scrum, Video

We handle risk in Agile differently than how we handle risk in traditional development. Because there’s more visibility into the risks, we are better able to mitigate them and deliver quality software. In this video, David Hawks explains the difference and why Agile can reduce the risk of delivery and increase predictability throughout an agile development.

Video Transcription (has been slightly edited for brevity and clarity):

Traditional Waterfall Risks

Hi, I’m David Hawks with Agile Velocity and today I’d like to talk to you about how we handle risk in Agile differently than how we handle risk in traditional development. In a traditional waterfall project, we start off with requirements, and then from there do design. Say this is a five-month project—we do a month of requirements, a month of design, two months of development and then we do testing at the end. Let’s say you’re the project manager and we get to the end of requirements phase and all of them are done and everyone had reviewed and signed off the document. Is the project green, yellow or red? We will probably report a green status. End of the design, end of month two, we’re still green. We get to the end of dev, all the code is done and checked in, the build is passing, so we report again that the project is green.

What is going to happen halfway through testing? We’re going to report we went red. Why did we go red all of a sudden? The reason is that this is the first point we’re validating anything upstream—that the code works, the code didn’t break anything else, that it meets the design, that it meets the requirements. And all of a sudden we’re red, we go to the management team and they’re like, “Oh my gracious, what happened? You’ve been reporting the project is green for 4 months. At this point, we told everyone we were 80% done.” What were we 80% done with at this point? We were 80% done with our plan, our schedule, our budget. But we’re probably not 80% ready to ship. We don’t have 80% of the features done.

So what we would do in the middle of the test, all of sudden, what are our options? We’re two weeks away from the delivery date, what can we consider to salvage our project? The options are things like add more time or extend the date. We could test less or fix fewer bugs. We won’t get as high a quality product out. So really what we’re doing at this point is sacrificing quality. Time and quality are our main levers. Some people will say, “We can cut features.” But can we? We’ve already done all the requirements, design and development. The features are there, we can only hide those features or not test and deliver those features with quality. We can throw more people at it. But that will probably affect quality. If we pull people from another project, it’s affecting the time of that other project.

The Risk Iceberg

These aren’t good options. And the reason for that is because we have what we call the “Risk Iceberg” problem. Every project has risks, but the problem is the water line is up there and we cannot see below the water line. We’re up here and for 80% of the time, all we could see was the tip of the iceberg. But then, when we got to test, all of a sudden, we look underneath the water line and we see that there’s a whole lot of risk. There’s a whole lot of issues, those risks show up in the form of defects and bugs. We find out that thing was there the whole time, we just didn’t see it because we’ve been working in a way that’s focused on assuming all our requirements are right and assuming our design is right and assuming our developers would write good code. Then we’d just have to verify it at the end. But the problem is that we’d get to verification and we’d fall on our face.

Agile Risks

How do we solve this from an Agile perspective? We’re going to work in sprints. The goal of the sprint is to get to a potentially shippable product increment. The way we do that is complete requirements, design, dev and test every single sprint. Every two weeks we’ll get something tested and fixed, we’re going to fix the bugs so that we’re going to get a potentially shippable product increment every two weeks. Principal 7 of the Agile Manifesto says that “working software is our primary measure of progress.” If we look at working software as our primary measure of progress up here, at the end of requirements, we had 0% working software, we had 0% at the end of design, and 0% working validated software at the end of dev. In waterfall, we said we’re 80% complete, but in Agile, we’re 0% complete because we have nothing of value we can deliver and we’re 4/5 of the way through our plan and we have no value.

But in Agile, we’re going to work on features and get them done-done at the end of every sprint. and if by the end of sprint 1, we finish 2 of 10 features of similar size, we would say we’re 20% complete and mean it. And if we finish at the end of sprint 2, 4 out of 10 features, we could say we’re 40% done and mean it. We could ship 40% of the functionality right now because it’s tested and working. And that allows us to engage with our stakeholders and potentially change the priorities of the things we haven’t worked on yet, it allows us to deliver value earlier. It has a lot of gains, but one of the biggest gains is that it leads to predictability because we don’t have the risk iceberg problem. Evey sprint we’re assessing the risk, we’re doing the testing in every sprint and looking under the waterline and we’re able to mitigate those risks. We usually mitigate bugs by fixing them and closing bugs to make sure we have a good quality state very sprint. If we do that, if we’re 4/10 features and we’re halfway through the schedule, then we’re probably yellow. We’re not green, we’re not on track, but we’re not necessarily way off track either. But we have an early warning indicator which allows us to mitigate risk.

Let’s look at our options if we get behind in an Agile initiative. First, we could reduce scope. We’re gonna push 2 features to our next release or sprints. We could add time, add another sprint into this release. But what we don’t have is a sacrifice of quality. That’s not an option because we’re investing in quality all along. And by investing in quality all along, that’s what allows us to reduce the risk of delivery and allows us to be more predictable throughout an agile development.

Blog

Why Backlog Refinement Should Be A First Class Citizen

By: David Hawks | Nov 29, 2017 | Article, Scrum

Backlog Refinement has been gaining momentum as a best practice in Scrum. I think it’s so important that I champion it to be a standard event, on par with Sprint Planning, Sprint Retrospectives, and Standups. (If you agree you should go to the Scrum Guide’s site and vote it up). I believe in order to be highly effective, the whole team should participate in this critical activity.

With the introduction of the Backlog Refinement event, you can address many challenges teams face. Most importantly, effective Sprint Planning, which will lead to a more stable and predictable delivery cadence. Let me share a story from a developer I know:

When I was a Director of Development, I would often need to lean on others as technical experts when trying to work through problems and solutions. We had a great lead developer on our team who I would collaborate with often named *Joe. I would grab Joe and head to a nearby whiteboard and sketch out my ideas, talking fast and drawing furiously. Meanwhile, Joe would have his hand on his chin and nod along in deep thought, taking it all in. I would get to the end and ask him what he thought, wanting to make a quick decision and move forward. However, Joe would say, “Let me think about it.” I would impatiently but respectfully say, “OK” and we would take a break. Later that day or the next, Joe would grab me and walk me back to the whiteboard. That’s how I knew he was ready to share his thoughts and work on a solution.

Do you know any developers like Joe? Individuals who have to wrap their head around the whole problem and look at it from all angles before they are ready to move forward? Most good developers are like that; that’s what makes them good. They think about all the things that could wrong so that they come up with a good, robust design.

So let’s think about what is happening to these poor developers when we conduct Sprint Planning without team-based Backlog Refinement prior to the meeting:

The developers walk into the Sprint Planning room without any idea of what they will be committing to that day. The ScrumMaster kicks off the meeting, explaining that in a second the Product Owner will share with the team the top items on the backlog. Then the team will have a few hours to commit to the next 2 weeks of their life. Surprise!

Developer love surprises, right? I don’t know about you, but I wouldn’t say developers embrace spontaneity. Isn’t that a cruel trick to play on them? Why don’t we spend a few moments ahead of time preparing the developers for what’s to come? That’s where Backlog Refinement comes in.

Backlog Refinement is an activity we recommend teams do every Sprint as a whole team with the Product Owner. There is no set timebox, however, I recommend about 1hr per week of your Sprint. I typically like to schedule this in the middle of the Sprint, right after the Daily Scrum for about two hours. So if we start our Sprints on Wednesdays and every other week is Sprint Planning, then the Wednesdays in between would be Backlog Refinement mornings.

The top priority of Backlog Refinement is to make sure we have enough work ready for the next Sprint. I like to set a goal to have 2-3 Sprints worth of Ready stories at all times. This ensures the team always has enough items to pull. There are two major elements to being ready:

Do we understand the work? – Have we reviewed Acceptance Criteria? Do we have any major open questions? Asking these questions days before Sprint Planning will allow the Product Owner to get all the answers.
Is the team going to be ready to start the work? – Do we have enough of a design strategy figured out to task it in Sprint Planning? Do we have any outside dependencies that need to be resolved first (i.e. access, DB, API, etc.)? Do we have the knowledge or do we need to get up to speed first?

The second focus is to partner with the Product Owner to break work down. Often, user stories start as Epics, and it is the team’s job to partner with the Product Owner to figure out the best way to break the functionality down into chunks that can lead to a Potentially Shippable Product Increment.

As we do this, we will need to resize the items, which leads to the third focus area: estimating. Most user story level estimating is done in Backlog Refinement, not Sprint Planning. Again, the goal is to get full team input on the size and to leverage everyone’s perspective. The Product Owner needs these estimates in order to properly prioritize the backlog prior to Sprint Planning. The team also often uses this time to ask the Product Owners questions to clarify scope and connections to other tasks or stories.

Some teams try and make this meeting more “efficient” by just sending the lead developer to represent the team. However, this leads to only one person understanding and ready to start the work while the other developers are still surprised when they walk into Sprint Planning. Who do you think they will rely on to create the plan for them? Will this be a shared plan and shared commitment or the lead developer’s plan? Would it be fair to hold the whole team accountable if it isn’t their plan?

If the team spends a few hours per Sprint together doing Backlog Refinement, then this will allow Sprint Planning to go smoother and faster. It will also limit the number of surprises that surface during the Sprint. Which, in turn, will lead to more predictable velocity and less rework of features. If we actually understand the scope of what we need to do before we even start, we might get a better product.

*Joe is not this person’s real name

Blog

Overview of an Agile Sprint Events Schedule

By: David Hawks | Nov 23, 2017 | Scrum, Video

Confused about the correct sprint ceremony schedule? Does the sprint planning come before or after the daily scrum? For new Agile practitioners, all of these meetings can be confusing and hard to keep track of.

David Hawks walks you through a sample 2-week sprint, with the timing for each ceremony, as well as the participants and time boxes.

Video Transcription (has been slightly edited for brevity and clarity):

Sprint Event Schedule

Hi, my name is David Hawks with Agile Velocity and today I’d like to share with you a typical sprint schedule. So, what we have here is a normal calendar, Monday through Friday. Hopefully, your teams aren’t working on Saturday and Sunday. And what we recommend is that you do 14 calendar day sprints, not 10 business day sprints. While that may seem the same, what we really want to do is focus on having a consistent cadence; so if we plan on a Wednesday, every other Wednesday we would do planning. If we do 10 business days and we have a holiday, so the next time would plan on a Thursday, and then we have a holiday and the next time we plan on a Friday, and it keeps the team from having a rhythm, or cadence. And as humans, we like rhythm, we like cadence.

We also recommend you do not start or end sprints on Mondays or Fridays. The reason for that is if you start and end Mondays or Fridays, you have a lot of the scrum events happening on Monday and Fridays. We have a lot of holidays and vacations and people out on Mondays and Fridays, so we don’t want to have events happening on days where we’re maybe not as focused or people consistently out on our team. What that means is we’d like to start our sprint on Wednesday or Thursday—which is what we’d typically recommend for a 2-week sprint. So, let’s say we start our Sprint on Wednesday morning, with the first scrum event, Sprint Planning. We’d start Wednesday morning with sprint planning for a two-week sprint, time-boxing it up to about a half a day. We would plan that time box and if we finished in 2 hours and 23 minutes, then great. Which means that 2 Wednesdays later, we’d probably have another sprint planning.

Daily Scrum

On Thursday, most teams choose to do their daily scrum in the morning. It doesn’t matter if you do the daily scrum in the morning, in the afternoon, right before lunch, or right after lunch, as long as it’s consistent throughout your sprint and it’s at the same time. We like rhythm, so it’s a dependable rhythm that every day at 9:30 we’re going to do a daily scrum. So if it’s in the morning, that means on that first Wednesday, we probably didn’t have a daily scrum because we didn’t have anything we were already working on, but we would have a daily scrum happening throughout our sprint and it’s time box for no more than 15 minutes. If we’ve done a good job of sprint planning, that means we should be able to finish our daily scrum in no more than 15 minutes.

Review and Retrospective

Now, the other thing is what would we end with? What are the two scrum events we would end our sprint two Tuesdays later? One is the sprint review the other is the sprint retrospective. You can do these in either order, there are pros and cons of doing one before the other. If you do the retro first, you can share in your sprint review with your stakeholders what you learned and what you’re going to do about it. The downside is the review doesn’t go well, you’ve already had your retrospective and you might not be able to take that feedback into your retro. The advantage of doing the review first is that you can retro on how the review went. You can do either way. For the review, just make sure it’s a time your stakeholders can make it.

We would have this kind of cadence throughout the sprint. Which means on the following Wednesday, we would start the day with another sprint planning. There are no gaps between one sprint ending and the next sprint starts, it just flows nicely into the next sprint. Some teams choose to do all the scrum events on the same day. Maybe on Wednesday, they are ending their sprint with their review and retro in the morning and then in the afternoon, they do sprint planning. Some teams like having all of them on the same day, but some teams hate having all day meetings. Do what works for your team.

Backlog Refinement

There’s one more event that I recommend, which is backlog refinement. There is no set timebox in Scrum Guide for backlog refinement, but I usually recommend 1 hour per week of your sprint. I recommend a practice of doing backlog refinement for a couple of hours in the middle of the sprint. I like to do it right after the daily scrum so it’s just 1 timebox asking developers to step away from their desk as opposed to fragmenting their day. It’s about 2 hours and sprint planning is up to 4 hours, daily scrum is 15 minutes. The good thing about doing backlog refinement on Wednesday is that you have a cadence of every Wednesday, we’re doing some type of planning —either sprint planning for the next two weeks or backlog refinement that’s preparing us for the upcoming sprints. Also, if we’re doing backlog refinement in the middle of the sprint, it leaves a couple of days for the product owner to get answers for any questions that come up and gives the teams some time to do any research to prepare for upcoming sprint planning.

The other timeboxes I didn’t mention: retro for a 2-week sprint is about 90 minutes. Again, if you finish in 63 minutes, great, but book 90 minutes so you don’t feel rushed. For the review, I recommend if you can do 30-60 minutes with your stakeholders, that’s pretty good. The book answer is no more than 2 hours for a 2-week sprint.

That is what a sprint would look like for a 2-week sprint.

More info via Scrum Alliance.

Blog

Inspect and Adapt: An Introduction to Agile Planning

By: David Hawks | Nov 16, 2017 | Video

Don’t make the hardest decisions at the dumbest point (ie. the beginning) in your Agile planning process. When we first start on a project, we rarely have a complete idea of what it takes to create a truly great product. There is always unexpected feedback or requirements that enter the picture.

In Agile, we plan and forecast for our projects like you would in traditional project planning. The difference is Agile Planning encourages us to inspect and adapt to feedback in order to create the best products for our users.

Familiarize yourself with the basics of Agile Planning with this quick video from David Hawks, and learn how to adapt as you encounter charges during product development.

Learn more about Agile Planning by reading our article on the subject: Don’t Lock in Tough Decisions Early.

Video Transcription (has been slightly edited for brevity and clarity):

Traditional Planning

Hi, I’m David Hawks with Agile Velocity. Today, I’d like to talk to you about Agile Planning and how that compares to traditional planning. When we do a traditional project, what I would typically do, pre-Agile, is I would have my starting point and then I would need to create a plan to hit some target out in the future. The way I would do that is I would go get estimates from all of what I used to call resources, and I now call people, I would get estimates from everybody and then start to build out the plan.

The plan would something like this–I need 2.2 days of one person’s time and 3.8 days of somebody else’s time. Meanwhile, one of my other resources would be working on this for a week. It was kinda fun, solving this puzzle of figuring out how to load-balance everybody. What’s the critical path? How do I get everything done? How am I am going to get everything done by the date? Now, I’d get to the end and I’d have a eureka moment where I had solved the puzzle. I had figured how we could get all this stuff done and I’d show it to senior leadership and they’d be like “Wow, you guys really know what you’re doing over there. You know what everybody is going to be doing every single day for the next six months. Because look at the plan, the plan shows what everyone should be working on. Every day mapped out for the next six months.”

Now, let me ask you this: when we created this plan, at the beginning of this project, is this our smartest point of the project? NO. This is actually our dumbest point. But we tend to make the hardest decisions and lock them in. These plans, which I now call Mythical Certainty: the level of precision of this plan doesn’t match the level of accuracy of our understanding of the requirements at the beginning. We have these very precise plans with a very imprecise understanding of the requirements, which leads to this illusion of certainty. The plan makes everybody feel good because once we have a plan, everyone says we have a plan, we have it all figured out. But the reality is, the plan is not perfect because the requirements are not perfect.

Agile Planning

So what do we do? What do we do in Agile? We could what we call hippie Agile: you have your developers, they come to senior leadership and say “Hey man, we’re agile. You’ll get it when you get it, man.” And I know a lot of developers that try to pull that off. But that doesn’t really work for businesses. We can’t just say, “We have no idea.” We do actually have an idea. We can forecast and actually in Agile, we plan and forecast a lot. We’re just responsive to change.

So what we want to do in Agile is acknowledge we’re at our dumbest point. Based on the information we have, we know we need to set out in the direction of the red target, but we’re going to apply empirical process control. And along the way, we’re going to constantly inspect and adapt based on the new information we get. And when we get a couple weeks in, we’re going to decide if we should keep heading in the direction of the red target, or based on what we have learned, and what new requirements have potentially come up, or new things that we need to do, we can decide to adapt our plan. And almost always, something will come up that we want to adapt to. And then we’ll head off in a different direction. We’ll apply a time-box and usually, in Scrum, it’s two weeks. And we’ll come back, and say, okay, based on that, do we want to keep going in that direction, or make another correction? We continually make these little inspections and adapt cycles along the path.

Now, is our goal to get back to the red target? Is our purpose to actually hit the red target? It isn’t. Our goal is not to hit the red target because the target was defined when we were at our dumbest point. We’re not trying to hit our red target, we’re trying to find a way to deliver the most value. The red target doesn’t guarantee that. So we’re typically going to continue to adapt until our time box is used up, or what our release schedule was set for, and we’re then going to find this new target. This new target allows us to maximize the most value possible over this period of time.

So, the fallacy in the red scenario is that we know everything up front and we just need to manage to the plan, manage to the red line to get to delivering the value that we set out to do. But, the reality is we have imperfect information so our goal is actually to accelerate learning throughout the cycle and get smarter about the problem and get smarter about potential solutions so we can deliver as much value as possible over this period of time to get to and find this new target. It’s somewhere around the red target but it’s not exactly where the red target is. And that’s what we’re trying to do from an agile planning perspective, it’s a change of mindset, not just a way of managing a project.

Blog

Top 5 Causes of Sprint Carry Over

By: David Hawks | Oct 10, 2017 | Article, Scrum, ScrumMaster

Most teams say they are doing Scrum, but they really aren’t. One of the core elements of Scrum is something called the Potentially Shippable Product Increment (PSPI), or getting to Done Done. Having an increment of your code/product potentially shippable at the end of every Sprint is the key to becoming predictable. And becoming predictable is key to being faster. If you can get a PSPI every sprint, your team will realize these three benefits:

Predictable delivery which will build trust with your stakeholders
Once you are predictable, your team will have measured improvement and gain speed
Being “Done Done” at the end of every sprint will enable adaptability and allow the business/ product owner to change priorities as the market demands

The goal at the end of every Sprint is to be Done Done with everything we planned in Sprint Planning. That means developed, tested and bugs fixed. The goal for Scrum teams should be over 80% of all Sprints complete 100% of their goal. Note I did not say every sprint that we only get 80% done and carryover 20%. Most of our Sprints we should get everything done. I find many teams get less than 60% of their plan done, carrying over 40% into the next Sprint.

Let’s explore the top reasons why teams carry over work on a consistent basis.

#1 – No Tasking

Sprint Planning has two parts: What and How. Many teams only talk about the What, the scope. They review stories and determine which stories they will do during the Sprint, but they don’t task them. This is creating a Commitment without an actual Plan. The event is called Sprint Planning, not Sprint Committing. The action of tasking is how we actually create a plan. We encourage teams to create tasks no bigger than a day, which in turn encourages design discussions to actually think through the work before starting. This might prompt more scope questions to get a better clarification of the work. Which ties into our second problem…

[If your teams have a lot of carryover each sprint, it could be a sign you’re not predictable yet. Download the 8 Common Pitfalls of An Agile Transformation to help identify trouble spots and areas of improvement.]

#2 – Don’t Understand the Work Before Planning

I find many teams start the work before they really understand the requirements. How can we commit to a plan with confidence if we don’t really understand what we are committing to? This happens because often Sprint Planning is the first time many of the team members have even seen the story they are to work on. This makes Sprint Planning more of a surprise party than a planning event. And we know how those spontaneous beings we call developers love surprises.

A best practice is to have the team do Backlog Refinement on a regular basis in preparation for upcoming Sprints. The whole team needs to be there so everyone is up to speed on the upcoming work and can ask questions. This also allows the Product Owner time to get answers to the team’s questions, versus getting those at Sprint Planning and not answering until halfway through the Sprint. During the Sprint we will always have scope clarification, but we do not want Scope Change.

#3 – Too many Dependencies

Many teams get into a Sprint and realize they have a dependency on another team and a story gets blocked. This could be due to a couple issues. First, do we have all the people we need to get the work done on our team? Second, should we have even pulled that story into our Sprint?

We want cross-functional feature teams, not component or architectural teams. The organizational team structure will help us minimize the number of dependencies outside the team and redirect them inside the team. If they are inside the team, we are only blocked by each other, which we can manage.

Also, we encourage teams to create a Definition of Ready (DOR). The DOR will help the Scrum Team agree on what state a story should be for us to pull into our Sprint. Some standard items might be:

The story has been reviewed by the whole team and Acceptance Criteria understand
There are no open major questions on scope
The story is sized and no bigger than X
We do not have any outside dependencies that may block our ability to finish this Sprint

Having a DOR will help the team and PO stay aligned on what is needed get a Story ready for our next Sprint.

#4 – No Known Velocity

You cannot improve what you cannot measure. We encourage teams to size their backlog in story points and measure velocity. Velocity is the average of how many points completed in previous Sprints. This allows the team to use “yesterday’s weather” to predict the future. However, if you do not size your backlog prior to Sprint Planning, then you will not be able to use this a predictive measure. We encourage teams to estimate story point during Backlog Refinement as a full team exercise. Once again, this gets everyone involved and helps prepare the team to plan during Sprint Planning. Once the team can measure velocity, then they can tune their engine. For example, I had a team that planned 20 points and got 15 done, they then planned 20 and again got 15 done. How many should they plan next Sprint? Right, 15. They should do 15 and get predictable and then start trying to do more. You have to go slow to go fast.

#5 – Working in Silos

I see many teams working in mini-waterfalls. Here is a common “bad” practice: A team of 4 developers pulls in 4 stories into their Sprint. Each developer works on their own story for almost all of the Sprint, each working in a silo. When working this way, developers question:

Why should they break their work down into tasks instead of just having an 80-hour task?
What’s the point of the Daily Scrum if I am just focused on getting my stuff done?

The goal of Scrum is Shared Team Ownership, where everyone works together with a shared commitment to the success of the Sprint. If we work in silos in a waterfall, we have a high probability of carrying work over into the next Sprint and big items.

Our goal is to prioritize, focus and swarm. This requires us to task early to coordinate who works on what. To be effective at swarming, we want some level of knowledge transfer during Sprint Planning so everyone understands what is involved. Swarming will lead to higher quality, but it also allows us to mark items “Done Done” early in the Sprint. Also, if we are working on Stories in priority order, it will guarantee we get the highest value items done.

Most teams want to move faster, however, if they aren’t predictable, they won’t get there. Team Backlog Refinement and Sprint Planning (with tasking) are the key elements to success. Most teams try to save time by shortening these meetings or involving fewer team members, but that only takes longer to get stories done and leads to be more rework. Remember, Stop Starting and Start Finishing. It is not about how much work you have in progress, it is about how much value you deliver at the end of every Sprint.

If your teams have a lot of carryover each sprint, it could be a sign you’re not predictable yet. Download the 8 Common Pitfalls of An Agile Transformation to help identify trouble spots and areas of improvement.