An Introduction to Agile and Scrum

Introduction to Scrum

source :

Training Facility UK
Trainers in personal development.
Teaching on Alison since Feb, 2023

What Is Scrum?

Scrum is a flexible way to create new products and services. With an agile method, you start by making a product backlog, which is a list of all the features and other capabilities that a successful product needs,

in order of importance. Using the product backlog as a guide, you always start with the most important or high-priority tasks. When you run out of time or other resources, the work that didn't get done will be less important than the work that did.

During each iteration, a self-organizing, cross-functional team does all the work, like designing, building, and testing, that is needed to make finished, working features that could be put into production.Usually, the amount of work in the product backlog is much larger than what a team can finish in a short iteration.

So, at the start of each iteration, the team decides which high-priority subset of the product backlog to work on. At the end of the iteration, the team reviews the finished features with the stakeholders to get feedback. Using the feedback, the product owner and team can change both what they plan to work on next and how they plan to do it.

Scrum Origins

Scrum's long history can be traced back to an article called "The New New Product Development Game" that was published in the Harvard Business Review in 1986. (Takeuchi and Nonaka 1986). This article

talks about how companies like Honda, Canon, and Fuji-Xerox used a scalable, team-based approach to all-at-once product development to get world-class results.

The 1986 article helped bring together many of the ideas that went into making what we now call Scrum. Scrum is not an acronym. Instead, it is a word that comes from the sport of rugby. In rugby, scrum is a way to start a game over after a mistake or when the ball is out of play. Jeff Sutherland and his team at Easel Corporation made the Scrum process for software development in 1993. They did this by combining ideas from the 1986 article with ideas

from object-oriented development, empirical process control, iterative and incremental development, software process and productivity research, and complex adaptive systems.

At OOPSLA 1995, Ken Schwaber wrote the first paper about Scrum (Schwaber 1995). Schwaber and Sutherland have written several books about Scrum since then, both together and on their own. These include Agile Software Development with Scrum (Schwaber and Beedle, 2001), Agile Project Management with Scrum (Schwaber, 2004), and "The Scrum Guide" (Schwaber and Sutherland, 2011).

Why Scrum?

So, why did Genomica decide that an agile method like Scrum was a good choice? First of all, it was clear that Genomica's old way of developing software just wasn't working. That was the bad news, but most
people agreed, which was the good news. Genomica worked in a complex field where there was more that wasn't known than what was known.

We made things that hadn't been made before. Our main focus was on cutting-edge, constantly changing, state-of-the-art discovery informatics platforms that research scientists could use to find the next blockbuster molecule. We needed a way to develop that would let us try out new ideas and approaches quickly and learn quickly which ones would work and which ones wouldn't. We also wanted our teams to have a wider range of skills.

In the past, Genomica worked like most other businesses. The work would not be given to the test teams until it was finished. We now wanted everyone on the team to talk to each other often—every day was the goal. In the past, mistakes were made because people talked about important issues too late in the development process. People in different places didn't talk to each other enough. Because of these and other things, we decided that Scrum would work well for Genomica.

Genomica Results

When we decided to use Scrum, it wasn't well known. The first book about Scrum didn't come out until the next year (Schwaber and Beedle 2001). But we put all the information we had together and did the best we could, which was a lot better than what we had done before.

With Scrum development, it took one-tenth as much work (measured in person-months) to build the same amount of product functionality as it did when we used a plan-driven, waterfall-style process. Also important is that the Scrum development went seven times faster than the waterfall development. This means that in the same amount of time, Scrum development made about seven times as many useful features as the waterfall development. Even better, we were able to give our partner the software in time for the launch of its new hardware platform, which was a big plus. This helped us strengthen a long-term partnership and raised the value of Genomica's shares by a lot.

Can Scrum Help You?

It's not unusual for a company like Genomica to have built features that nobody wanted and delivered them late and with low quality before Scrum. Genomica, like many other companies, had made it this far by not being worse than its rivals.

What would your business people and developers say if you asked them today, "Are you happy with the results of our software development efforts?" or "Do you think we give our customers good value in a timely, cost-effective, and high-quality way?"

Most of the time, the people I train and coach around the world answer both questions with a strong "No." Customers are always happy with these companies because they give them what they really want, not just the features they asked for on the first day when they didn't know what they really needed.

By putting out smaller updates more often, they are also getting a better return on their investment. And by always pointing out dysfunction and waste in their organisations, these groups are able to cut costs.

Benefits of Scrum

Scrum's focus on delivering working, integrated, tested, and business-valued features at the end of each iteration makes it possible to get results quickly.

Scrum is also a good way for organisations to do well in a complex world where the actions of competitors, customers, users, regulatory bodies, and other stakeholders all affect each other and must be changed quickly. And Scrum provides more joy for all participants.

Customers are happy, and the people who do the work actually like what they do. They work together often and on important projects, which helps them get along better with each other and trust each other more.

Benefits of Scrum Diagram

Software Development

First, it's important to realise that the many parts of software development and support won't fit neatly into just one Cynefin domain. Software development is a complex process with parts that overlap and activities that fall into all of the different domains (Pelrine 2011). So, even though most software development work is complicated or complex, it would be naive to boldly say that software development is a complex field. This is especially true if we define software development as all the work that goes into making new products, maintaining software products, and running and supporting them.

Scrum Framework

Overview

Scrum is not a standard process where you follow a set of steps in order that are guaranteed to make a high-quality product on time and on a budget that makes customers happy. Instead, Scrum is a way to organise and control how work is done. The Scrum framework is based on a set of values, principles, and practices.

These provide the base on which your organisation will add its own implementation of relevant engineering practices and your own ways of putting the Scrum practices into action. You'll end up with a version of Scrum that is completely your own. To better understand what a framework is, think of the Scrum framework as a building's base and walls.

The main building blocks would be the Scrum values, principles, and practices. You can't ignore or change a value, principle, or practice in a big way without putting the whole thing at risk. You can, however, change Scrum's structure by adding fixtures and features until you have a method that works for you.

Scrum Activities and Artifacts

Sprint Process Diagram

The Sprint

Let's summarise the diagram by working clockwise around the main looping arrow, starting on the left side of the picture (the sprint). The person in charge of the product has an idea of what he wants to make (the big cube).

Because the cube can be big, it is broken down into a set of features through a process called "grooming." These features are then put into a list of priorities called the "product backlog."

A sprint starts with sprint planning, includes the development work done during the sprint (called sprint execution), and ends with a review and retrospective. The big, looping arrow in the middle of the figure is a symbol of the sprint.

Sprint Planning and Backlogs

There are probably more items on the product backlog than a development team can finish in a short sprint. So, at the start of each sprint, the development team must decide which parts of the product backlog they think they can finish. This is called sprint planning and is shown to the right of the big product backlog cube.

During sprint planning, team members make a second list, called the sprint backlog, to make sure that the development team has made a reasonable promise. The sprint backlog is a list of detailed tasks that will show how the team plans to design, build, integrate, and test the selected subset of features from the product backlog during that sprint.

Sprint Execution

The next step is sprint execution, where the development team does the tasks needed to build the chosen features.

During sprint execution, the team members help manage the flow of work by doing something called the daily scrum, which is a synchronisation, inspection, and adaptive planning activity.

At the end of sprint execution, the team has made a potentially shippable product increment that represents some, but not all, of the product owner's vision.

Sprint review

The Scrum team completes the sprint by doing two "inspect-and-adapt" activities. In the first, called the "sprint review," the stakeholders and the Scrum team look over the product as it is being made. In the second, called the "sprint retrospective," the Scrum team looks at how the Scrum process is being used to create the product.

The result of these activities might change that get added to the product backlog or become part of the team's development process. At this point, the Scrum sprint cycle starts over, with the development team deciding which of the next most important product backlog items they can finish.
After the right number of sprints have been done, the product owner's vision will be realised, and the solution can be released.

Sprints

Sprints are limited by time, so they always have a set start and end date, and they should usually all last the same amount of time.
After the last sprint is done, a new sprint starts right away.

Sprint Process

Sprint Planning

A product backlog may include many weeks or months of work, which is much more than can be done in a single, short sprint. Sprint planning is done by the product owner, the development team, and The ScrumMaster to figure out which parts of the product backlog are the most important to build in the next sprint.

Many development teams break each feature they want to create into a set of tasks so they can be sure they can do it. Most Scrum teams that make sprints that last between two weeks and a month try to finish sprint planning in about four to eight hours. A planning session for a one-week sprint shouldn't take more than a couple of hours (and probably less).

An alternative would be for the product owner and team to choose all of the target product backlog items at once. The development team does the task breakdowns by itself to make sure it can really deliver all of the selected product backlog items.

Agile Principles

Variability and Uncertainty

Plan-driven processes treat product development like manufacturing. They don't like change and want people to stick to a set process. The problem is that making a product is nothing like making a product. In manufacturing, the goal is to take a set of fixed requirements and a set of well-understood, sequential steps to make a finished product that is the same every time.

In product development, on the other hand, the goal isn't to make a lot of products but to make one unique product. This single instance is analogous to a unique recipe. We don't want to make the same recipe twice, because then we've wasted our money. Instead, we want to come up with an original recipe for a new product. To make a different product each time, there must be some variation. In fact, every feature we build within a product is different from every other feature we build within that product, so we need variation even at this level.

Employ Iterative and Incremental Development

Scrum is based on developing in small steps and in cycles. Even though these two terms are often used as if they mean the same thing, iterative development and incremental development are not the same. Iterative development recognises that we will probably get things wrong before we get them right and that we will do things badly before we do them well (Goldberg and Rubin 1995).

So, iterative development is a strategy for reworking that is planned. We use multiple passes to improve what we are building so that we can get to a good solution. For example, we might start by making a prototype to learn important information about a part of the product that we don't know much about. Then, we might make a slightly better version, which might be followed by a version that's pretty good.

The basic idea behind incremental development is to "build some of it before you build all of it." We try not to have one big event at the end of development where everything comes together and the whole product is delivered. Instead, we break the product into smaller parts so that we can build some of it, learn how each part works in its environment, change it based on what we've learned, and then build more of it. With incremental development, we learn important things that help us change how we develop and how we move forward.

Leverage Variability

A plan-driven, step-by-step development process assumes that the output won't change much, if at all. It has a clear set of steps and doesn't use much feedback until the end of the process. Scrum, on the other hand, is based on the idea that some level of change is needed in product development in order to make something new.

Scrum also assumes that the process needed to make the product is complicated and can't be fully explained at the start. At the heart of Scrum are the principles of inspection, adaptation, and transparency. Schwaber and Beedle (2001) called these together empirical process control. In Scrum, we look at both what we're building and how we're building it and make changes to both.

Prediction and Adaptation

Scrum says that we should never make a decision too soon just because a generic process says it's time to make a decision. Instead, we like to keep all of our options open when we use Scrum. This principle is often called the last responsible moment (LRM) (Poppendieck and Poppendieck, 2003), which means that we don't make big, permanent decisions until the last responsible moment.

When will that be? When the cost of not making a choice is more than the cost of making a choice, it's time to choose. To understand this principle, think about this. On the first day of making a new product, we know the least about what we are doing. Every day that we work on the project, we learn a little bit more.

Prediction and Adaptation Diagram

Accept That You Can’t Get It Right Up Front

In Scrum, we know that we can't get all of the plans and requirements right away. In fact, we think that trying to do so could be dangerous because we might be missing important information, which could
lead to a lot of low-quality requirements being made.

More on Prediction and Adaptation

This figure shows that when we use a plan-driven, sequential process, we come up with a lot of requirements early on, when we know the least about the product as a whole. This method is risky because it gives the impression that we know what will happen in the end.

Balance Predictive Up-Front Work With Adaptive Just-in-Time Work

Finding the balance

Plan-driven development is based on the idea that detailed requirements and planning should be done at the beginning and before moving on to later stages. In Scrum, we think that work done right away
should be useful without being too much. We know that it's not possible to get all of the requirements and plans right away with Scrum.

Does that mean we shouldn't do any work on needs or plans right away? Of course not! Scrum is about finding a balance between work that is planned ahead of time and work that is done as it is needed.
How that balance is reached depends in part on the type of product being built, the level of uncertainty in both what we want to build (end uncertainty) and how we want to build it (means uncertainty), and the constraints on the development.

Predictive Up-Front Vs Adaptive Just-in-Time Work

Validated Learning

When we use Scrum, we set up the work so that we can quickly create validated learning, a term that Ries (2011) came up with. Validated learning is when we get information that proves or disproves an assumption we have made.

Validate Important Assumptions Fast

Assumptions represent a significant development risk. We try to keep the number of important assumptions to a minimum in Scrum. We also don't want to let important assumptions stand for too long without testing them. When iterative and incremental development is used together with a focus on low-cost exploration, assumptions can be tested quickly. So, if we use Scrum and make a fundamentally wrong assumption, we are likely to find out about it quickly and have a chance to fix it. In plan-driven, sequential development, the same bad assumption that is tested too late could cause the development effort to fail in a big way or fail completely.

Leverage Multiple Concurrent Learning Loops

In Scrum, we know that the key to our success is to learn new things all the time. When we use Scrum, we look for and take advantage of feedback loops to help us learn more. In this style of product development, there is a pattern of making an assumption (or setting a goal), building something (doing some activities), getting feedback on what we built, and then using that feedback to compare what we did to what we assumed.

The Scrum framework is also flexible enough to work with a lot of different kinds of learning loops. For example, technical practise feedback loops like pair programming (feedback in seconds) and test-driven development (feedback in minutes) are often used with Scrum development, even though they are not required by Scrum.

Work in Process (WIP)

Work in progress, or WIP, is work that has been started but has not yet been completed. During product development, WIP needs to be identified and managed in the right way.

Use Economically Sensible Batch Sizes

In Scrum, we agree that economies-of-scale thinking has been a key part of manufacturing for a long time, but that applying it rigidly to product development will hurt the economy in a big way. Even though it seems counterintuitive, working on a product in smaller batches has many benefits. Reinertsen discusses batch-size issues in depth.

Recognize Inventory and Manage It for Good Flow

Manufacturers are very aware of their stocks and how those stocks affect their finances. How could they not? Inventory quickly starts to stack up on the floor, waiting to be processed. The inventory in a factory can be seen both physically and financially.

Ask the CFO of a manufacturing company how much inventory (or WIP) he has in the factory or how much it has changed in the last month, and he will give you a clear answer. In product development, it's important to remember that requirements are just one kind of inventory. During the development of a product, we have WIP in many different places and at many different times. We also need to proactively find and handle those.

Focus on Idle Work, Not Idle Workers

Many organisations that work on making new products care more about getting rid of the waste of idle workers than the waste of idle work. Traditional thinking says that if I hire you as a tester, you should spend all of your time testings. If you don't spend 100% of your time testing, I lose money because you're not testing when you could be. So that this doesn't happen, I'll find you more testing work—maybe by putting you on more than one project—so that your utilisation goes up to 100%.

Unfortunately, this method cuts down on one type of waste (waste from idle workers) while increasing another type of waste (idle-work waste). And most of the time, the cost of doing nothing is much higher than the cost of a worker doing nothing.

Timeboxed

Sprints are based on the idea of timeboxing, which is a way to manage time that helps organise how work is done and keep track of its scope. Each sprint happens in a timebox, which is a set amount of time with a start and end date. Inside this timebox, the team is expected to work at a pace that they can keep up with to finish a set of tasks that match a sprint goal. There are several reasons why timeboxing is important, which are shown in the next screenshot.

Timeboxing Benefits

Importance of Timeboxed

Establishes a WIP Limit

Timeboxing is a way to limit the number of work-in-progress (WIP) items (work in process). WIP is a list of work that has been started but is not yet done. If you don't manage it well, it can hurt your finances in a big way. Timeboxing sets a WIP limit for each sprint because the team will only plan to work on things it thinks it can start and finish in that sprint.

Forces Prioritization

Timeboxing forces us to decide what's most important and does only that small amount of work. This makes us more determined to get something important done quickly.

Demonstrates Progress

Timeboxing also helps us show the progress that matters by finishing and validating important pieces of work by a certain date (the end of the sprint). This type of progress reduces organisational risk by taking the focus off of less reliable ways to report progress, like "conformance to plan." Timeboxing also lets us show progress on big features that take more than one timebox to finish. Getting some work done on these features makes sure that each sprint shows the progress that is useful and can be measured. It also shows the stakeholders and the team what needs to be done to finish the whole feature.

Avoids Unnecessary Perfectionism

Timeboxing helps people stop trying to be too perfect. We've all spent too much time trying to get something "perfect" or "gold-plated" when "good enough" would have been enough. Timeboxing puts an end to work that could go on forever by giving the sprint a fixed end date by which a good solution must be done.

Improves Predictability

Timeboxing makes things more predictable. We can't say for sure what work we'll do in a year, but it's reasonable to think we can say what work we can do in the next short sprint.

Short Duration Sprints and Their Benefits

Short-duration sprints provide many benefits:

Ease of Planning

It's easier to plan when sprints are short. Planning for a few weeks of work is easier than planning for six months of work. Also, planning for such a short amount of time is much easier and more accurate than planning for a longer period of time.

Fast Feedback

When sprints are short, feedback comes quickly. During each sprint, we build software that works, and then we can look at what we built and how we built it to make changes. This quick feedback lets us get rid of unfavourable product paths or development approaches quickly before a bad decision leads to a lot of other bad decisions that are tied to it. Fast feedback also lets us find and take advantage of time-sensitive opportunities more quickly.

Improved Return on Investment

Short-term sprints not only improve the economy by giving quick feedback, but they also make it possible to get things done faster and more often. Because of this, we can start making money sooner, which makes our overall return on investment better.

Bounded Error

Short-duration sprints are also bound errors. How wrong can we be in a two-week sprint? Even if we fumble the whole thing, we have lost only two weeks. We insist on short-duration sprints because they provide frequent coordination and feedback. That way, if we’re wrong, at least we’re wrong in a small way.

Frequent Checkpoints

Scrum gives managers, stakeholders, product owners, and others a lot more checkpoints than they

would have with sequential projects. At the end of each short sprint, there is an important checkpoint

called the "sprint review" that lets everyone make decisions based on features that have been shown to work. People are better able to deal with a complicated environment when they have more opportunities to inspect and change at checkpoints.

Consistent Duration

As a general rule, a development team should choose a consistent length for its sprints and stick to it unless there is a good reason to change it. Among the most convincing reasons could be:

You're thinking about switching from four-week sprints to two-week sprints so you can get feedback more often, but you want to try a couple of two-week sprints first.
Because of holidays or the end of the fiscal year, it's easier to run a three-week sprint instead of the usual two-week sprint.
Since the release of the product happens in one week, a two-week sprint would be a waste of time.

Cadence Benefits

Sprints that last the same amount of time give us cadence, which is like the heartbeat of a Scrum development effort. A steady, healthy heartbeat helps the Scrum team and the organisation learn

important rhythms about when things need to happen to get a fast, flexible flow of business value. A regular cadence when sprinting also makes it much easier to coordinate. With fixed-length sprints, we can plan sprint planning, sprint review, and sprint retrospective activities for many sprints at the same time. Since everyone knows when the activities will take place, it is much

easier to schedule them for a large number of sprints.

Simplifies Planning

Using a consistent length of time also makes it easier to plan activities. When all sprints are the same length, even if they are shorter than usual because of a holiday, the team gets used to how much work it can do in a typical sprint (referred to as its velocity). Most of the time, speed is compared to a sprint. If the length of a sprint can change, we don't really have a standard unit for sprints. It would not make sense to say things like, "The team's average speed per sprint is 20 points.

Definition of Done

In module 2, I talked about how the result of each sprint should be a possible shippable product increment. I also said that "possibly shippable" doesn't mean that what was built must actually be shipped. Shipping is a business decision that is often made at different intervals. In some organisations, it may not make sense to ship at the end of every sprint.

Definition

Potentially shippable is better thought of as a level of confidence that what was built in the sprint is actually done. This means that there isn't any important unfinished work (like important testing, integration, etc.) that needs to be done before we could ship the results of the sprint if that was what our business wanted.

A well-defined, agreed-upon definition of "done" is needed for the Scrum team to figure out if what they've made might be shippable. Conceptually, the definition of "done" is a list of the types of work that the team needs to finish before it can say that its work might be ready to ship.
Most of the time, a bare-minimum definition of done should result in a complete slice of product functionality that has been designed, built, integrated, tested, documented, and would deliver validated customer value. To make a useful check list, though, these bigger-picture tasks need to be broken down even more.

Breakdown of Done Definition

No Goal-Altering Changes

But once a product or project is approved and we start adding more details to its product backlog items, we need to change how we estimate. When PBIs have become more important and have been honed to
include more details, most teams prefer to use either story points or ideal days to estimate how long they will take. I'll talk more about both of these later in the module.

One of the most important Scrum rules says that once the sprint goal has been set and sprint execution has begun, nothing can be changed that would change the sprint goal in a way that would be noticeable. Each sprint has a goal that describes the business purpose and value of the sprint as a whole.

Most of the time, the sprint goal has a single, clear focus, such as:

Help create the first report.
Load and edit map data for North America.
Show that you can send a text message through a software, firmware, and hardware stack that works together.

Sometimes, a sprint goal will have more than one part. For example, "Make basic printing work and add support for searching by date" is more than one thing.

During sprint planning, the development team should help refine and agree on the sprint goal and then use it to figure out which product backlog items it can finish by the end of the sprint. These items from the product backlog help to explain the sprint goal in more depth.

Using Conversations

In sequential product development, written requirements are very important, but they can be hard to understand. I remember a conversation I had with the Vice President of Product Management at a business I went to.

I asked this person, who was in charge of all the business analysts in the company, how they dealt with requirements. He said, "My team gives the engineering group the requirements document on January 1, and on December 31, we show up to see what we got." I asked him who on his team would be available throughout the year to answer questions from developers and make sure they understood what was expected of them. He said, "No one. My group spent all of the time we had on this project writing the requirements document. My analysts are working

on requirements documents for other projects while they are not here. But don't worry, we wrote a good document, and if the developers or testers have any questions, they can find the answers by reading the document carefully.

We use conversation as a key tool in Scrum to make sure that requirements are properly talked about and shared. Verbal communication has the benefit of being fast and high bandwidth, which makes it easier and cheaper for people to understand each other. Conversations also allow two-way communication, which can lead to ideas about problems and opportunities that wouldn't come up if you just read a document. A conversation is just a tool, though. It doesn't replace all documents. In Scrum, the product backlog is a "living document" that is always available while a product is being made.

Progressive Refinement

In sequential product development, all requirements must be at the same level of detail at the same time. In particular, the approved requirements document must list each and every requirement so that the teams doing the design, build, and test work can understand how to meet the specifications.

There isn't anything else to add. There are many problems with making all requirements have the same level of detail at the same time:

We have to figure out all of these details early on in the process of making a product when we know the least.
We treat all requirements the same, no matter how important they are. This means that we have to spend time and money on details for requirements that we may never build.
We make a big list of requirements that will probably be very expensive to change or throw away if things change.
Because the requirements are already "complete," we are less likely to use conversations to expand on and clarify them.

Not all requirements have to be at the same level of detail at the same time when using Scrum. The requirements we'll work on right away will be smaller and more specific than the ones we'll work on later. We use a strategy called "progressive refinement" to break up large, vague requirements into a set of smaller, more specific items. This is done just in time.

What Are User Stories?

User stories are an easy way to describe the business value that is wanted for many different types of product backlog items, especially features. User stories are written so that both business people and technical people can understand them.

They are easy to put together and make great pauses in a conversation. Also, they can be written at different levels of detail and are easy to improve step by step. So, what are user stories exactly? Ron Jeffries gives a simple way to think about user stories that work well (Jeffries 2001). He calls them the "three Cs," which stand for card, conversation, and confirmation.

Card

The idea for the card is pretty basic. People used to write user stories right on index cards or sticky notes that were 3 inches by 5 inches. Many people still do this. The card isn't meant to hold all of the information needed to meet the requirement. In fact, we use small cards with limited space on purpose to encourage shortness. A card should have a few sentences that explain what a requirement is all about. It gives the stakeholders, the product owner, and the development team a place to start talking about more details.

Conversation

In a conversation between the development team, the product owner, and the stakeholders, the details of a requirement are brought out and shared. The user story is just a promise that this talk will happen. One of the benefits of user stories is that they shift some of the focus from writing to talking. These talks make it easier for people to share information and work together to make sure that the right needs are communicated and understood by everyone. So we're not getting rid of all of our documents in favour of user stories and their associated story cards. User stories are just a good way to get to the heart of what is wanted and a good reminder to talk about requirements in more detail when necessary. But user stories can and should be supplemented with whatever other written information helps make it clear what is wanted.

Confirmation

A user story also includes confirmation information in the form of conditions of satisfaction. These are acceptance criteria that explain the behaviour that is expected. The development team uses them to know what to build and test, and the product owner uses them to make sure that the user story has been implemented to his satisfaction.

If the story is described in a few lines on the front of the card, the conditions for satisfaction could be listed on the back. The story's acceptance tests exist for a number of reasons. First, they are an important way to record and communicate, from the product owner's point of view, how to know if the story has been implemented correctly.

Level of Detail

Story Points Release Flow Management

User stories are a great way to move things that are valuable to customers or users through the Scrum value-creation flow. But if we only have one story size, which is the size that fits well into a short sprint, it will be hard to plan at a higher level and get the most out of progressive refinement.

Most of the time, when I say "stories," I mean the smallest types of user stories. Some people call these "stories" "sprintable stories" or "implementable stories" to show that they are small enough to fit into a sprint and be done.

This is to avoid confusion with "epics," "features," and other larger "stories" that are also called "stories." It's important to remember that terms like "epic," "feature," "story," and "theme" are just labels for convenience, and not everyone uses them. It doesn't really matter what labels you use as long as you do so consistently.

What matters is knowing that stories can be told at different levels of abstraction, and that doing so helps us plan at different levels of abstraction and break down big things into smaller ones over time.

Gathering Stories

How do user stories come into existence? In traditional ways of gathering requirements, users are asked what they want. I have never had much luck with that method. From what I've seen, users are much better at criticising than they are at writing.

So, if you ask a user, "What do you want?" she might or might not be able to tell you. Even if she does answer the question and we build exactly what she asked for, she may say, "Yes, you gave me exactly what I asked for, but now that I see it, I want something else." I'm sure we've all been through something like this.

A better way to do things is to include users on the team that decides what to build and keeps checking on what is being built. To encourage this level of participation, many organisations prefer to use user-story writing workshops as the main way to come up with at least the first set of user stories.

User-Story-Writing Workshop The goal of a user-story-writing workshop is for everyone to come up with ideas about what business value they want and what the product or service should do. If it's the first workshop, I usually start by doing user role analysis. The goal is to find the set of user roles that can be used to fill in the user role parts of our stories. We might also have personas, which are modelled versions of people who have the most important

qualities of a role. There is no standard way to make user stories during the workshop. Some teams like working from the top down, while others like working from the bottom up. With the top-down method, the team starts with a big story (like an epic) and then focuses on making a good collection of smaller stories that are connected to the epic. An alternative is to work more bottom-up and start right away to come up with ideas for stories that are related to the next release of an existing system.

Product Backlog

Product Backlog Items

Backlog items, which I call PBIs, backlog items, or just items, make up the product backlog. Most PBIs are features or pieces of functionality that give the user or customer something they can use. PBIs are often written like user stories, but Scrum doesn't say how they should be written.

A login screen for a new website is an example of a brand-new feature. A login screen that is easier to use is an example of a change to an existing feature. Other PBIs include problems that need to be fixed, technical improvements, work to learn something new, and any other work that the product owner thinks is important.

PBI Illustration

Good Product Backlog Characteristics

Good product backlogs have similar qualities. Roman Pichler (Pichler, 2010) and Mike Cohn came up with the acronym DEEP to sum up a few important qualities of good product backlogs: Detailed well, Emergent, Estimated, and Prioritized. Just as the INVEST criteria can be used to judge the quality of a user story, the DEEP criteria can be used to see if a product backlog has been set up in a good way.

Detailed Appropriately

As we get closer to working on a big PBI, like an epic, we'll break it up into a set of smaller, sprint-ready stories. This should happen just in time. If we refine too early, we might spend a lot of time figuring out the details and never get to the story. If we wait too long, we will block the flow of PBIs into the sprint, which will slow the team down. We need to find the right amount of just enough and just in time.

Emergent

As long as a product is being created or fixed, the product backlog will never be finished or frozen. Instead, it is constantly updated based on a constant stream of economically valuable information. The product backlog is made so that it can adapt to these situations. So, the structure of the product backlog is always changing. As new items are added or existing ones are improved, the product owner must rebalance and reprioritize the product backlog to reflect the new information.

Estimated

Each item on the product backlog estimates how much work it will take to create. The product owner uses these estimates as one of several factors to help decide a PBI's priority (and, by extension, its place in the product backlog). Also, a large, high-priority PBI near the top of the backlog tells the product owner that the item needs more work before it can be moved into a sprint in the near future.

Prioritised

Even though the product backlog is a list of PBIs in order of priority, it is unlikely that every item on the list will be prioritised. Prioritising the tasks that will be done in the next few sprints is helpful. Maybe it's best to set priorities as far down the backlog as we think we can get in Release 1. It probably isn't worth our time to keep going past that point at anything other than a basic level of priority. We should probably not waste our time worrying about how to prioritise features that we might work on in Release 2 or Release 3 in the future. We might never do Release 2 or Release 3, or our ideas about those releases might change a lot as Release 1 is made. Prioritising that far in advance is probably a waste of time.

Grooming

To get a good, DEEP product backlog, we need to proactively manage, organise, and administer the product backlog, or "groom" it as it is often called.

What Is Grooming?

Grooming is a set of three main tasks: making and improving PBIs (by adding details to them), estimating
PBIs, and putting PBIs in order of importance.

Grooming Diagram

More on Grooming

All PBIs need to be estimated at the right time so that their order in the backlog can be determined and so that it can be decided if more refinement work is needed. Also, when important new information comes in, new items are made and put in the right order in the backlog.

If our priorities change, we'll need to reorder the items in the backlog, of course. And as we get closer to working on a bigger thing, we'll want to break it down into a set of smaller things. We might also decide that a certain backlog item doesn't need to be done and delete it.

Who Does the Grooming?

The product owner is in charge of grooming the product backlog, but a lot of internal and external stakeholders, as well as the ScrumMaster and the development team, are also involved. In the end, only the product owner can make decisions about grooming.

But good product owners know that collaborative grooming encourages important conversations between all participants and uses the combined intelligence and perspectives of a diverse group of people to find important information that might be missed otherwise.

Flow Management

A product backlog is a key tool that helps the Scrum team deliver value quickly and in a flexible way, even when there is uncertainty. Product development can't be done without uncertainty.

We must assume that there will always be a steady flow of economically important information coming in, and we must organise and manage the work (manage the product backlog) so that this information can be processed quickly, cheaply, and in a way that keeps the flow going. Let's look at what the product backlog does to help the release flow and sprint flow work well.

Release Flow Management

The product backlog needs to be sorted in a way that helps with ongoing release planning (the flow of features within a release). A release can be pictured as a line through the product backlog. All of the PBIs above the release line are slated to be in that release, but the ones below the line are not.

These two lines divide the backlog into three sections: must have, nice to have, and won't have. The "must-have" features are the things that must be in the next release or else it won't be a good customer release. The nice-to-have features are things we want to include in the next release. If, however, we run out of time or other resources, we could drop features that would be nice to have and still be able to ship a good product. The won't-have features are things that we've decided not to include in the current release.

Sprint Flow Management

Product backlog grooming is necessary for good sprint planning and the flow of features into a sprint that comes from it. If the product backlog is detailed enough, the things at the top of the list should be easy to understand and test. For good sprint flow, it helps to think of the product backlog as a pipeline of requirements that flow into sprints for the team to design, build, and test.
In this figure, we can see that larger, less well-understood requirements are being added to the pipeline.

The grooming activity improves them as they move through the pipeline and get closer to the time when they will flow out to be worked on. The team is on the right side of the pipe. When an item comes out of the pipeline, it must be ready, with enough information for the team to understand it and feel confident
that it can be delivered during a sprint. If the items coming in and going out don't match or aren't the same, we have a problem. If the flow of finished, detailed, and ready-to-implement items is too slow, the pipeline will run dry and the team won't be able to plan and carry out the next sprint (a major flow disruption or waste in Scrum).

On the other hand, putting too many things in the pipeline for refinement creates a large number of detailed requirements that we may have to change or get rid of once we know more (a major source of waste). So, the best situation is to have just enough product backlog items in inventory to create a steady flow, but not so many that they go to waste.

Sprint Flow Management Diagram

Estimation and Velocity
What and When We Estimate
Most organisations make estimates at three different levels of detail to help them plan. The portfolio backlog, the product backlog, and the sprint backlog are all places where these estimates show up. Let's take a quick look at each.

Estimation and Velocity Diagram

Portfolio Backlog Item Estimates

Even though the portfolio backlog is not a part of Scrum, many companies keep one. It is a list of all the products or projects that need to be built, in order of priority. To put items in a portfolio backog in the right order, we need to know how much each one will cost.

When this cost number is first asked for, we usually won't have a full, detailed list of requirements, so we can't use the standard method of estimating each individual, detailed requirement and then adding those estimates to get a rough idea of the total cost.

Product Backlog Estimates

Task Estimates

Tasks are measured in ideal hours. The team thinks it will take five effort-hours to finish the UI task. It doesn't mean that it will take five hours. It could take one person a couple of days or less than a day for two people to work together to code the user interface. The estimate just says how much work is expected from the team to finish the task.

PBI Estimation Concepts

Even though all three levels of detail are important, this chapter will focus on estimation at the product backlog level. When estimating PBIs, Scrum teams take into account a number of important ideas. Let's examine each concept.

Estimate as a Team

In many traditional organisations, the first size estimate might be done by the project manager, product manager, architect, or lead developer. At a later time, other team members might be able to look at and comment on these estimates. In Scrum, we stick to a simple rule: the people who will be doing the work give the estimates as a group.For clarity, when I say "people who will do the work," I mean the development team that will actually design, build, and test the PBIs. The product owner and the ScrumMaster don't provide estimates. Both of these roles are there when PBIs are being estimated, but they don't do any actual estimating.

To be clear, when I say "people who will do the work," I mean the development team that will do the actual work to design, build, and test the PBIs. The product owner and ScrumMaster do not provide estimates. Both of these roles are present when the PBIs are being estimated, but they don't do any hands-on estimating. The product owner's job is to describe the PBIs and answer any clarifying questions that the team might have. The product owner should not lead or "anchor" the team toward a desired estimate. The ScrumMaster's job is to help coach and coordinate the estimation activity. The goal is for the development team to figure out the size of each PBI from a group perspective.

More PBI Estimation Concepts

Estimates Are Not Commitments

Estimates are not promises, and it's important not to treat them like they are. Most of the time, this statement is about managers. "What do you mean we aren't asking the team to commit to its estimates? How will we get accurate estimates if they don't?" When this subject comes up in my classes, I show how it works with a simple visual. I hold up a sticky note and say, "Imagine that I ask you how big this story is and you tell me it's this big." Then, as shown on the left, I use my hands to show how big the story is. The estimates should give a realistic idea of how big something is. We don't want them to get inflated by outside forces. This kind of behaviour only leads to bloated schedules and a back-and-forth game in which team members increase their estimates and management lowers them.

Accuracy versus Precision

Our estimates should be right, but they shouldn't be too right. We've all worked on products where the estimates were so accurate that they were ridiculous. We should put in enough work to get a rough estimate that is good enough. When estimating, there will always be a point of diminishing returns where more effort doesn't make the estimate more accurate. After that, we're just wasting time and probably starting to hurt the accuracy of the estimate by looking at more and more low-value data.

PBI Estimation Concepts Diagram

PBI Estimation Units

Even though there is no standard unit for estimating PBI sizes, story points and ideal days are by far the most common units. If you have to choose between these two, there is no right or wrong answer. I'd say that 70% of the organisations I work with use story points and 30% use ideal days. Let's examine each.

Story Points

Story points tell how big or important a PBI is. We think that story points will be affected by things like complexity and size. To be big, something doesn't have to be physically big.

The story might show how a complicated business algorithm is made. Even though the end result won't be very big, the work to make it might be. On the other hand, a story might be big in size but not hard to understand. Let's say we need to change all 60,000 cells on a spreadsheet.
None of the updates is hard on their own, but they can't be done automatically. How much of this work can we do in a single week? Even though it's not hard, this would be a very long story.

Ideal Days

A different way to figure out PBIs is to use "ideal days." Ideal days are a common unit that shows how many person-days or effort-days it takes to finish a story. Ideal time is not the same as the amount of time that has passed.
In an ideal American football game, there are four 15-minute quarters, so the whole game takes an ideal hour. But playing the game takes more like three to three and a half hours. I've already said that there is no right or wrong choice between story points and ideal days. But the risk of being misunderstood is a big thing that works against ideal time.

What Is Velocity?

Velocity is the amount of work finished in each sprint. It is measured by adding up the sizes of the PBIs that are done by the end of the sprint. A PBI is either finished or not. The product owner doesn't get any value from things that aren't done, so the size numbers of partially completed PBIs aren't included in velocity. Velocity is also a diagnostic metric that the team can use to evaluate and improve how it uses Scrum to deliver value to customers. By keeping track of its own velocity over time, the team can learn how changes to specific processes affect the delivery of measurable customer value.

Calculate a Velocity Range

For planning, velocity is most useful when it is given as a range, like "The team can usually finish between 25 and 30 points each sprint." By using a range, we can be exact without being too exact. With a speed range, we can answer questions like, "When will we be done?" more accurately. "How many things can we finish?" or "How much will this all cost?" Most of these questions are asked early on in the process of making a product, when we know the least about it, so it's hard to give a precise answer. We can show how uncertain we are by using a range.

Forecasting Velocity

One common way to predict a team's velocity is to have the team do sprint planning to figure out what PBIs they can commit to delivering in a single sprint. If the commitment seems reasonable, we'd just add up the sizes of the committed PBIs and use that number to estimate the team's speed. We really want a range of speeds, so we could have the team plan two sprints and use one-speed estimate as the high and the other as the low (the two estimates would likely be different). Once the team has done a sprint and we have a real measurement of speed, we should throw out the estimate and use the real one.

Lesson Summary

The key contents covered in the module are:

Scrum can help you deal with the changes of developing complex products.
A sprint starts with sprint planning, includes the development work done during the sprint (called sprint execution), and ends with a review and retrospective.
The product owner clearly defines what the Scrum team is trying to accomplish and shares it with everyone else.
The ScrumMaster helps everyone understand and follow Scrum's values, principles, and practices.
The development team organizes itself to figure out how to achieve best the goal the product owner sets.
Iterative development recognizes that we will probably get things wrong before we get them right and do things badly before doing them well (Goldberg and Rubin 1995).
Plan-driven development is based on the idea that detailed requirements and planning should be done at the beginning and before moving on to later stages. In Scrum, we think that work done right away should be helpful without being too much.
Sprints are based on timeboxing, a way to manage time that helps organize how work is done and keep track of its scope.
The benefits of timeboxing include an established WIP limit, forced prioritization and improved predictability.

Cari Blog Ini

Ansori