Part 6 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015.
The last problem is this: everything’s important, everything’s high priority, everything must get done. (more…)
Part 5 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…
The fifth problem… we’re not getting things done. This is the Scrumbut part of Scrum. “Yeah, we do Scrum but we carry over stuff every sprint. The work just doesn’t fit in two weeks.” We have to figure how to break work down so it can be finished in a sprint. If not, we’re not getting to done and we’re not getting that potentially shippable product increment.
Illusion of Progress
Let’s say we have a waterfall project that is projected to be a 5-month project and we’re going to do requirements, design, two months of development and a month of testing. You are the project manager who is responsible for red-yellow-green status. We’re going along and we finish the requirements in the first 4 weeks and we get it all reviewed, signed off and all the changes integrated. We’ve finished requirements in first four weeks of a five-month project. Are we green, yellow or red? Green! We finished on time. We get the design done on time, reviewed, validated and signed off. What color are we now? Green! We’re 40% complete. And then we do the development – the code is written, checked in, built and integrated—finished on time by the end of month 4. Still Green!
What happens a week or two into testing? We turn red. Like a deep good wine, red. But wait, at this point weren’t we 80% done? But what were we 80% done with? The time, the schedule, the requirements at the beginning (we think!). We’re at least done with our schedule and probably our budget at this point. But now all of a sudden we’ve gone red.
How do we salvage this project and get back to green? What are our options?
Push the date. Time is always an option. Politically maybe not always a good option, but it is an option. What else?
Cut features. Let’s think about that – requirements, design, and development are all a sunk cost at this point. We can’t go back and do less development so it looks like the scenario from last time, “Hey that feature you’ve been working on, can you just go comment it all out because it’s not going to make the release.”
Test less. Maybe our release criteria at the beginning of the project were to fix all Sev 1 and Sev 2 defects. Then all of a sudden we’re red and we say only fix the really bad Sev 1s. “We’ll do a quick patch right after we release.” So now we’re sacrificing quality and time. Or we could just not test parts of the scope – “I think it’s pretty stable and no one uses that feature anyway.”
These aren’t good options. We’re finding things out too late. Think about an iceberg – a risk iceberg. All we can see is the tip and we’re just able to mitigate some of the risks through the first phases of the project and then we hit testing and there are all these issues underneath the waterline. Testing is the first time we’re revealing the quality of our product and there are usually things that are wrong. There’s a reason why QA has a job!
Working Software is our Primary Measure of Progress
At that point, it’s too late for us to address many of those issues. In Agile and Scrum, we work in sprints, we want to get to done. And there’s this joke about being done done – are you done… or are you done done? Did you meet the definition of done? Is it potentially shippable? We want to work in slivers of functionality. That doesn’t mean that we have to release every two weeks; we’re saying the work is of quality that it could be released. So if you were building something like an Amazon site and in this sprint the team completed the shopping cart functionality, but you couldn’t do credit card processing yet, is it potentially shippable? What if I said that we tested and can add products of all different types, remove items, change quantities and all of that works with no major bugs. Is it potentially shippable? Is it of quality that it could ship? Yes. But is it valuable enough to ship yet? No. Those are two different things. The Product Owner could decide we need to get this feature out there and see if anyone adds items to the cart. “We’re going to do a big launch – come add items to your cart; in two weeks you’ll be able to buy it.” Maybe that makes sense.
Sometimes there is a business reason to ship, but what the main goal is to be able to validate progress – working software is our primary measure of progress—not a finished a requirements document (“we’re 20% done”), not code complete (“we’re 80% done”), but potentially shippable. So if we have 10 features to get done over the next four sprints and after sprint two we have 4 of 10 features done, we’re 40% complete and we mean it. In that case, would you say we’re green, yellow or red? We’re 40% done and we’re halfway through the time. We’re yellow. We get early warning indicators now. We’re able to assess the risk every two weeks. A wise director of QA once told me, “We can release anytime you want. My job is to assess the risk of releasing right now.” And that’s what we’re able to do—we can assess, address and mitigate the risks by fixing the bugs that we find every two weeks so that we’re potentially shippable.
And this is the Rosetta stone of Agile—if you can finish things that are small and potentially shippable every two weeks, then it allows you to deviate from the orange line earlier. It allows you to assess the impact of change and you have the agility to pivot as the requirements change in the business. But if you’re working on big long features carried over from sprint to sprint, you’re not able to do that. So we’ve got to figure out how to break work down. How do we work in a cross functional way where we have development and QA on the same team, getting things all the way to the finish line during the sprint?
Let me walk you through a scenario. This was a real life case when I was learning Agile and I thought I had figured it out. We’ve figured out Agile—we’ve got sprints, we’re going to test inside these sprints and we’re using story points. We had two weeks sprints and we planned 20 points into each sprint and then a hardening sprint at the end. 
Points are a relative measure—20 points is twice as much work as 10 points. With 20 points worth of work planned for each sprint, in 10 weeks we would have 80 points complete (no points in the hardening sprint). And our definition of done was that we were not only building it but also testing it and we had a good amount of automation (we thought we were rocking this agile thing). We were fixing as many bugs as would fit in our timebox, but any other bugs we’d put in our hardening sprint. We just kept moving those to the hardening sprint. And how long do you think that hardening sprint took? It ended up taking 8 weeks. So really what happened is that we delivered 80 points in 16 weeks.
Go Slow to Go Fast
It looked like we were getting a lot done every two weeks and we were telling ourselves we were getting a lot done, but we realized we needed to be more disciplined about our definition of done. We needed to go slow to go fast. So next time, we said our definition of done now includes fixing all bugs (of high enough severity) that are required to release. And then we did 15 points in every sprint, so in 10 weeks we got 75 points done. That’s almost double the work, in half the time. And all we did was go slower.
The developers argued they could do 20 points! No, you can’t. You can get 20 points coded, but not tested and all the way to done. So a question to ask is… what is the job of the developer? Is the job of the developer to write code or to deliver value and outcomes? We need to get them involved in discovery. We need to get them involved in quality. We need to get them involved in getting things all the way to the finish line. It’s not just about how many lines of code they’re writing; that’s not the bottleneck. The bottleneck is releasing a bunch of bad software that is missing the mark. We need to be delivering software that is solving problems and meeting the needs of our customers.
Stop Starting, Start Finishing
We have the saying “Stop starting, start finishing”. It’s easy for us to start work and it’s easy for the business to come up with new ideas. And as managers, what we normally do is a cycle of a new idea comes in, we triage it and assign it to out, another new idea comes in, we triage and assign it and now it’s off my plate so I can go play golf. But we need to block those batons up front because it’s easier for us to manage the queue of work that we haven’t started than to manage all the work in all of these queues. And if we have a lot of queues, then our cycle time becomes really long. So we want to not start stuff until we finish. Don’t just shove more paper in the printer, wait until we get something done and then pull the next highest priority thing in. And prioritization becomes a lot easier for the Product Owner. Because if we finish two things every week, we just look at the list for the next two things. We don’t need to prioritize 100 items, we just need to know the next two. We can work on those and get those done.
In order to get to done, a key Agile capability, you and your teams will need to break some tough habits. Sometimes, extra guidance via Agile coaching can help. Learn more about our supplementary Agile coaching services like agility tune-ups here. Next topic in the Double the Value in Half the Time series: Prioritize
Part 4 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…
So we’ve got all of these challenges…. and one of them is a problem I call Drowning in a Sea of Opportunity. For most companies, this is their #1 problem.
When we go into an organization, we learn everything is a high priority. Everything’s urgent. It all has to get done. The VP of Sales has already promised it, so we just need you to do it. It’s like shoving more paper into a printer—is it going to come out faster on the other side? No! It’s just going to jam up. The goal is not 100% utilization, despite what some managers think. What’s 100% utilization of the main highway on Friday at 5:00 pm? A parking lot. Is anything moving? No, but it’s 100% utilized. When all resources are 100% utilized, they’re running around crazy and unfocused, but they’re busy!
Focus on the Work, not the Worker
We have this saying: Watch the baton, not the runner. The runners are the people doing the work; the baton IS the work. And in most of our organizations what’s happening is a baton, a new idea, comes in and it sits in a queue until it gets enough priority and then an analyst or Product Owner picks it up and gives it some definition. Then it sits in a queue until a developer picks it up, then it sits in a queue until QA picks it up sometime later. And in a perfect world, it would go sit in another queue until it gets deployed.
But there’s a reason why QA exists, right? At a happy hour, we had a quality coach who once said, “I want to make a toast.” She looked at the developers and continued, “I want to thank you guys. I have a job because you suck.” Funny, but true. Once an item gets to QA, the reality is that it’s going to go back to Development because they don’t write perfect code. So, if we focus on the baton—not the runner—how long does it take for the baton to get through? In most organizations, there are batons all over the floor, with very few of them are in anybody’s hand and getting to the finish line.
For example, let’s look at juggling lots of batons at one time. We have 9 projects and 9 developers. It would seem to be more “efficient” to assign one project to each person. Say each project is about a month long and two weeks in, I ask “what percentage complete are you?” Two weeks into a month-long project, they would probably say, “About 50%.” But what happens if something changes? A new requirement? Something that’s now 3rd on the priority list. What are our options? What can we do?
We would probably tell Mark, who’s working on the 9th priority, to jump on this new project. And we might tell John, who’s working on the 8th priority, we need him on this new one too. But we’d tell them to remember where they were because, in two weeks, they’ll need to go back to it. So just comment out all that code? Or better yet, put a feature toggle on it? No, that’s not really a great option. What else can we do? Ignore the new priority? Say no? “We don’t have enough resources so we’ll just we’ll get to it later.” Those aren’t great answers for the business. Or we could just go with the Office Space example and say “I need you guys to work on Saturday… and maybe Sunday too.” None of these are good options.
When we work on a bunch of things at once it seems to be more efficient, but we’re not getting outcomes delivered. We’re not getting things done and we don’t have a good measure of progress.
But if we swarm and focus on one thing at a time, then when we ask the team, “what percentage complete are you?” we’d get a different answer. If they focus, then the team could say “we’ve finished four items and we’re about done with the fifth.” While we probably couldn’t put nine people on one project, maybe we’d work on two things concurrently.
This is one of those new skills Agile teams have to figure out—how to break work down. Not only how to break stories down, but how to break tasks down and share the work. If I just say I work on blue stuff, Mark works on the red stuff and I have a two-week blue task to do, Mark doesn’t know how to help me. But if I break the blue task down into database work, unit tests, development, UX work to design, etc, then Mark might say “I know how to do database stuff, I can help with that part.” Once we break work down, it forces the developers to think things through. That’s what we do in sprint planning. But the Product Owner also shares some responsibility by writing stories that meet the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable chunks of work. That’s what enables us to get to the potentially shippable product increment at the end of the sprint.
Next topic in the Double the Value in Half the Time series: Getting to Done
Part 3 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…
The third problem holding teams back is long feedback loops. Some of us have long feedback loops, while others have no feedback loops at all! And therefore we’re not learning. We’re not getting new information.
Eric Ries’ “The Lean Startup” challenges the way we think about developing products.
Picture two loops happening at the same time. Most of the time we’re focused on the execution loop: How do we execute? How do we deliver software faster? How do we do it with higher quality? How do we shorten feedback cycles? How do we increase productivity?
But there’s another loop we haven’t talked about enough – the product discovery loop. Are we building the right product? What product should we be building? What features should we be building? While both of these are happening at the same time, many times it seems the Product Owner is off on an island and is supposed to just guess what product to build and then the developers iterate on building it over here in the execution loop.
Eric Ries says to think about everything we build as a science experiment, not a requirement. We hear the word requirement and we assume it’s a fixed factual thing. It’s a requirement! But really, a requirement is nothing more than a hypothesis. If we build this thing, we expect that outcome. We got really good at coming up with an idea and building it, delivering the product, going to the next idea. That was our loop. But are we building the right product and features? We should be measuring and learning from it. I like to think of it backwards – What do we need to learn? How are we going to measure that we’re learning? What’s the needle we’re trying to move? What’s the smallest thing we can build or test?
There’s a story about a debate at Amazon where a group is discussing features and initiatives and what’s going to make the most money. Part of the conversation went like this:
"Let's just put a link to the website on the homepage."
"But we haven't build the website yet!"
"I don't care."
"What's it going to do?"
"Go to a 404 error."
They did just that and… nobody clicked the link. Do they need to build that feature? No! If people started clicking it, they could take the link down and go build the website. They built a minimal feature, measured its use, and learned that it was not worth investing the time and money to continue building on it.
Indeed has a lot of stories around product discovery in their blog. Last year they recorded a bunch of videos around how they’re doing experiment-driven development. Data-driven development is what they’re calling it. They’re running over 100 experiments at any given time, things are always changing. They’re trying to discover what’s the smallest thing we can build to experiment with and learn from, to validate or invalidate our hypothesis?
Eric Huddleston runs TrendKite. He is a smart dude who says our job is to figure how dumb we are as fast as possible. Because everything we’ve convinced ourselves is right, our “perfect” requirements? Most of those things are wrong and it’s a lot cheaper to figure that out before we’ve written all the code, integrated, tested, and released it. And that’s usually when we find out if we’re wrong… if we ever do.
Next topic in the Double the Value in Half the Time series: Focus!
If you’re still not seeing the value from your Agile investment, you might benefit from an Agile assessment. One of the benefits of an Agile assessment is understanding where teams are now, in terms of key capabilities, so that you can create a backlog (next steps) for your transformation. Go here to learn more about Agile assessments.
Part 2 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…
The second problem in the “Deliver Double the Value in Half the Time” series is that the Team doesn’t have a shared understanding of their purpose.
Finding the Right Requirements
Many of us have lived in a world of three false assumptions:
- The customer knows what she wants
- The developers know how to build it
- Nothing will change along the way
The reality is we live in a world of constant discovery:
- The customer discovers what she wants
- The developers discover how to build it
- Many things change along the way
Creating a shared understanding takes an investment of time. A common thought may be that developers are paid to write code, so that’s what they should be focused on, not sitting in a meeting to talk with Product Owners or Stakeholders to actually understand what it is they’re building. Some organizations will decide to have someone, maybe a Business Analyst, figure it out and write it up and then feed that under the door to the Team with a pizza and then just expect them to build what’s written out. How’s that working out? Are we effectively communicating what it is we are trying to build and more importantly, are we effectively iterating through to validate all the assumptions that we have going into it?
A great technique to develop shared understanding is User Story Mapping (see “User Story Mapping” by Jeff Patten for more details). Get your team and stakeholders in a room together and get them talking. Make the switch from “requirements delivery” to a “requirements discovery” process.
Requirements delivery means what is to be built communicated through a big requirements document – we expect the Team to read it, we expect the Team to understand all the stuff that was analyzed over the last x weeks or months and we expect them to understand it because it’s communicated through the document. But there’s no such thing as perfect requirements. So getting the team involved in the discovery process, doing something where they are interviewing stakeholders and walking through scenarios of what the customer is going to do (like user story mapping) is really valuable time spent. Through story mapping, the Team gains knowledge of what the customer is trying to do.
One team who builds a consumer-based product took half a day to go to the mall to interview customers. Think they built better software after actually talking to real customers? Definitely! Teams are making decisions every day about what the software’s going to do and how it’s going to behave. If they have no understanding of who the customer is or what that customer wants, they’re going to make it up as they go. If we don’t give developers clarity, they will get really creative: “I can imagine…” ,”Wouldn’t it be cool if…??”. “No, it wouldn’t!” Because we’re not going to get our product shipped. And there are all these other features on the list and they’re not that cool… but the customer wants them. They don’t need the coolest. We’re trying to get the Team to focus on building the minimal thing, getting it out there and learning from it. Let’s accelerate learning, let’s make sure we understand the problem we’re trying to solve, and not just giving the Team solutions to go build. It’s common for teams to need guidance to reach this next level. Go here if you’re interested in learning more about our supplementary Agile coaching services like agility tune-ups.
Next topic in the Double the Value in Half the Time series: Shorten Feedback Cycles.
Part 1 of 6 in the Double the Value in Half the Time series based on David Hawks’ presentation from Keep Austin Agile 2015 . Stay tuned for subsequent posts…
Traditional Project Planning
Traditionally we create our plans up front at our Dumbest Point. We take our requirements, get our estimates, set our target and lock it in.
I used to love creating this plan, since I enjoy a tough puzzle. How can I take all the estimated tasks of varying sizes and allocate those efficiently across all my “resources”? I would open up MS Project and start dragging things around, assigning Resource 1 to work on Task 1 for 2.2 days and then pick up Task 2 for around 3.8 days. Meanwhile, Resource 2 would be allocated 70% to one task and 30% to another. Once those dependencies were completed at the end of week 1, then Resource 3 could start their item.
This would continue until the end and I’d have this Eureka moment when I had solved the puzzle. Everyone was perfectly load balanced with my “perfect plan”. I would present it to executive management, who would look at it and say, “Awesome! You guys really must know what you’re doing over there based on the precision of this plan.” You know what I call those plans now? Mythical Certainty. They provide an illusion of accuracy in our estimates and in our understanding of the user’s needs. And do you think my “perfect plan” was open to change? No way!! Any big changes along the way would totally disrupt the my “perfect plan”.
So are we creating these plans at our smartest point? No! Not only are we making these plans at our dumbest point, but we tend to lock them in.
Continuous Agile Planning
It is a fallacy in Agile that we don’t plan. The reality is we plan and re-plan continuously. If we are using our empirical process control we should be constantly inspecting and adapting. We progress in a series of Sprints in Scrum, and after each Sprint we will inspect our progress, review what we learned and potentially pivot on our path.
This is done all in an effort to deliver the most value possible given the constraints of time and budget (or, as in most cases, the size of your allocated team).
This is where the third Agile Manifesto value statement comes into play:
“Customer Collaboration over Contract Negotiation”
Our goal is not to just manage to the plan, but to maximize the value delivered. To accomplish this, we need to Accelerate Learning throughout the project and involve customers in the process. If we aren’t reaching a Potentially Shippable Product Increment every Sprint, we won’t accomplish this. The Potentially Shippable Product Increment is the Rosetta Stone that unlocks so much in Agile. If you carry over work from Sprint to Sprint, you can’t pivot. If your Definition of Done does not include testing and bug fixing, then you don’t know if your software works, thus deferring risk.
The third element of an empirical process is transparency and it is critical to accomplish this consistent pivoting. This is where Principle #7 in the Agile Manifesto comes into play:
“Working software is the primary measure of progress”
Only if we truly finish working verified items, will we learn and understand what progress we are making towards the goal. Only then we will gain the required insight to pivot to the best outcome possible. While your teams are getting gains from Agile, getting to done and delivering working product increments is a hard capability to acquire. It’s common for teams to need guidance to reach this next level. Go here if you’re interested in learning more about our supplementary Agile coaching services like agility tune-ups.
Next topic in the Double the Value in Half the Time series: It’s About Requirements Discovery, Not Just Delivery.
Blog
Using Agile to Deliver Double the Value in Half the Time Series
By: David Hawks | Apr 10, 2015 | Article
As we work with software product teams, we see more struggling than success with Agile. After conducting many assessments, we’ve found almost all organizations have the potential to deliver double the value and cut their delivery time in half. In this series, I will explore 6 of the top problem areas holding most organizations back.
Let’s assume a starting point of V=T, i.e you are delivering on time and all the intended value over this period of time. By accelerating learning and focused swarming, we will show you how to achieve 2V=.5T, or Double the Value in Half the Time.
Too often in our industry, we are overly obsessed with optimizing for output. We make sure everyone is busy and fully utilized. We try to keep our developers out of meetings and coding at all times. I even had a CEO at one of our clients ask the VP of Development, “If we could send the developers to typing class, would we get more features out the door?” I agree with Henrik Kniberg,1 our goal instead should be maximizing outcome with the least amount of output.
“Outcome over Output”
The Standish Group has reported approximately 64% of features we build in the software industry are rarely or never used.
To illustrate, if I asked you to draw as many houses you can in 2 minutes and you just started drawing, you could get a bunch done. But, do you think you would deliver any that I actually wanted?
Should we continue to build more of the wrong things? Should we just keep everyone busy? Is 100% utilization the goal? Do you want 100% utilization of your CPU? What does 100% utilization of the nearest highway during rush hour look like? The answer is no, because slack allows for change.
Our goal is to not just keep everyone busy cranking out widgets—an idea left over from Industrial Era management. If we were running a repeatable process of manufacturing iPhones, slack for change isn’t needed because we are building the same thing over and over. In that world we have a Defined Process Control Model.
“A defined process is an amount of tightly coupled steps where the output from one step is the input to the next step and where no observation or evaluation of the output is done to feedback to the process. A defined process, when started, will run to the end without any checkpoint. The output from a defined process should always be the same or with little variance given the same input to the process.
For many years software development methodologies have been based on the defined process control model. But software development isn’t a process that generates the same output every time given a certain input.”
-Ken Schwaber in Agile Software Development with Scrum
After the first 100 items out of the assembly line, could you predict with a high degree of certainty how long to get the next 1,000 or next 10,000? Probably. Does that feel like software development? Isn’t it just building more pages, reports, screens? No, but a non-technical CEO sees it as a factory and wants the repeatable results typically associated with a factory. The difference is that every feature is different in software, so it’s not building the same thing over and over again. And that thing is always changing.
If I ask a developer to estimate the time to build the same exact feature they finished yesterday 100 more times, I bet she could estimate with a high degree of certainty. However, she would quit before getting to the 100th because developers are creators. Each task is more than the implementation it requires—elements of design, innovation, problem solving, and learning. This is why agile methods are centered around Empirical Process control instead of Defined Process Control.
Empirical Process Control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.
Scrum adopts an empirical approach accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
-Ken Schwaber in Agile Software Development with Scrum
We need to constantly inspect and adapt in order to accelerate learning. Let’s explore the first problem we encounter in most organizations:
Problem #1 – We make tough decisions too early and lock them in
Problem #2 – It’s about Requirements Discovery, Not Delivery
Problem #3 – Long Feedback Loops
Problem #4 – Focus
Problem #5 – Getting to Done
Problem #6 – Prioritize
Note: If you are struggling with Predictability, we recommend focusing there first before trying to increase productivity.
¹Product Owner in a Nutshell Video
We need your help! Agile Velocity is putting together a video about Scrum dysfunction and are looking for input on what dysfunctions to cover and what tips to offer.
Here are some dysfunctions we see to get the creative juices flowing:
DYSFUNCTION: Someone starts a side discussion while others are talking
DYSFUNCTION: Someone rambles on until they’re asked to move on
And here are some tips and tricks we like to use:
TIP: Have a talking ball that the team passes around
TIP: Create a rule to keep long talkers to a minimum like the ELMO rule (Enough Let’s Move On)
What problems has your team encountered? How did you solve it? What worked, what didn’t? Please share your dysfunctions and tips with us below in the comments.
Looking for more? Click here to assess the effectiveness of your Daily Scrums
This is the fourth post in our Scrum Assessment Series.
Often we’ll attend a Sprint Review where the team is present and ready to demonstrate the work they completed during the Sprint, but there are no stakeholders or customers present to see the demo! Or maybe stakeholders are physically present but busy checking their phones or disengaged in some other way. Or perhaps the demo during the Sprint Review is the first time the Product Owner is seeing the final result of the team’s Sprint work.
None of these scenarios are ideal! The primary goal of the Sprint Review is to show off the work completed in the Sprint to engaged stakeholders who are giving their feedback on the work.
You can use the following questions to assess how effective your Sprint Reviews are:
The Basics
- Was the whole team in attendance including ScrumMaster and Product Owner?
- Were stakeholders present?
- Did the team drive the demo?
- Is the team prepared, but not over-prepared? (They shouldn’t spend more than an hour preparing for the Review for a two-week sprint.)
Good
- Was the focus on demonstrating the working software, project, product, etc?
- Were the stakeholders engaged?
- Were new items added to the backlog as a result of the stakeholder’s participation?
- Is the team accepting feedback without being defensive about it?
- Does the Review feel like a celebration of the work completed?
- Did Product Owner sign-off occur before the Sprint Review?
- Is it short enough to keep the stakeholders engaged, but long enough to be valuable?
- Does it happen every Sprint?
- Are only completed stories being reviewed?
- Are the team members keeping their presentation to a business level? i.e. Not getting into the technical weeds?
Awesome
- Are stakeholders interacting with the demo?
- Were metrics like the sprint burndown or progress on the release burnup shared?
- Were any other teams represented?
- Did the Product Owner discuss the scope and priorities for the next sprint?
- Was progress on the overall project or release discussed?
- Are stakeholders excited about coming?
- Is management present and encouraging the team to keep learning and improving? Are they asking how they can help?
Here are some ideas you can implement to help improve your Sprint Review:
- Make sure to talk with your stakeholders to customize the Sprint Review to their needs. Is it at a time that works for them?
- Make it a fun event. Encourage clapping after each story. Bring cookies or beer and make it a celebration.
- Consider taking the demo to stakeholders if you can’t get them to come to you. Go to their part of the office.
- If you have a team room, do the Sprint Review in that room. Have team members pair up with stakeholders to walk them through features.
- We typically have a rule that only features that have been signed off by the Product Owner can be presented at the Sprint Review. Meaning it has to be “Done Done“. No partially completed work. This encourages teams to finish on time.
- Make sure with new teams no one is getting too caught up in metrics or feeling negative about missed stories. Make sure the focus is on continuous improvement and encourage the team to share what it is learning and what it is improving. Management should find out what they can do to help remove impediments for the team.
- Consider conducting your Retrospectives before the Sprint Review so the team can share their learnings and action plan.
- If the team is interested in having a more technical discussion about the implementation with each other or other technical stakeholders, consider breaking the session into two. One part for the business review and the other for the technical review.
View other posts in our Scrum Assessment Series.
Fine-tune your Agile skills and become a Certified ScrumMaster or Certified Scrum Product Owner.
What items have you implemented that improved your Sprint Reviews?
Blog
Release Planning: Improve your Visibility into Release Progress
By: David Hawks | Feb 20, 2014 | Article,
Scrum
This is the fifth post in our Scrum Assessment Series.
Often teams are working on features over multiple sprints scheduled in a release. Planning and tracking these releases can be very difficult, but you can’t tell the business we have no idea what will be delivered. Since it is impossible to perfectly define the requirements upfront, we can’t perfectly predict when we will be done.
However, that doesn’t mean we don’t plan. In Agile, we plan all the time with a lightweight method to forecast the schedule and then revise as we obtain new information. This is why it is critical for agile teams to focus on delivering “Done Done” product increments every couple weeks. We can then use “Working Software” as our primary measure of progress and update our forecast. This also helps us better assess the impact of change throughout the plan.
You can use the following questions to assess how effective you are at Planning and Tracking Releases:
The Basics
- Is the team involved in release planning?
- Does the team do the estimating?
- Does the team have a sense of their velocity or throughput to use as a basis for forecasting?
- Are release burnup and/or burndown charts updated frequently?
- Are stakeholders involved in prioritization?
- Is an initial release plan in place before the start of the first Sprint of the release?
Good
- Is a vision or goal articulated for the release?
- Does the team plan for discovered or unplanned work?
- Is risk factored into the plan estimates?
- Does the team use an abstract relative estimation technique (i.e. Story Points or T-shirt sizing)?
- Is the release progress reported in the Sprint Review and discussed with stakeholders?
- Are release burnup and/or burndown charts visible to the team at all times?
- Are cross-team dependencies considered and discussed?
- Do stakeholders consider the size when prioritizing?
- Are the backlog items ordered?
- Are all large epics broken down into Minimally Marketable Features (MMFs) before starting the first Sprint of the release?
- Are stories understood by the team?
- Is the business and team continuing to try and make releases shorter?
Awesome
- Does the team release so frequently that release planning is not required?
- Does the team have a high level of predictability and comfort with their sizing technique?
- Does the business understand and accept the variability of working in an empirical way?
- Does the order of the backlog make learning a priority?
- Is change expected?
- Does the order of backlog items factor in risk? (i.e. deferring some items to the last responsible moment)
- Is the impact of change assessed and communicated?
Here are some ideas you can implement to help improve your Release Planning:
- Have you looked into a risk-based forecasting model? Check out a chapter from the Art of Agile Development from James Shore.
- Ensure your team is investing time in advancing its technical practices as well to shorten the cycle time of your releases.
- When you have multiple teams working on the same release consider conducting a release planning working with all teams simultaneously
- Estimate using Story Points
- Henrik Kniberg does a good job discussing the different types of risk in his video Product Owner in a Nutshell. He also discusses the concept of variability in planning.
View other posts in our Scrum Assessment Series.
What items have you implemented that improved your Release Planning?