Contents

Agile Scrum Explained ............................................................................................................................................. 3

Agile Planning .......................................................................................................................................................... 4
Three initial levels of planning: ........................................................................................................................... 4
Scrum Roles and Responsibilities ............................................................................................................................ 5
Development Team ............................................................................................................................................. 5
Who is needed to complete the product increment?..................................................................................... 5
What are DEV Team Activities?....................................................................................................................... 5
Product Owners .................................................................................................................................................. 5
What is the Product Owner Scrum Process? .................................................................................................. 5
What does a Product Owner do? .................................................................................................................... 6
Scrum Master ...................................................................................................................................................... 6
Responsibilities................................................................................................................................................ 6
Differences from the classic Project Manager ................................................................................................ 6
Scrum Artifacts / Definitions ................................................................................................................................... 7
User Stories ......................................................................................................................................................... 7
Product Backlog Items......................................................................................................................................... 7
Product Backlog Attributes.............................................................................................................................. 7
Product Backlog Includes ................................................................................................................................ 7
Sprint Backlog Items............................................................................................................................................ 7
Sprint Backlog Attributes................................................................................................................................. 7
Burn Down Chart ................................................................................................................................................. 8
Possible Reporting Metrics; ............................................................................................................................ 8
ESTIMATING - SIZING (Relative) and Hourly (Ideal Effort) Estimating ................................................................ 8
SIZING – Product Backlog and User Story levels ............................................................................................. 8
ESTIMATING – Sprint Backlog or Task level .................................................................................................... 8
Story Point Estimating ..................................................................................................................................... 8
Planning Poker .................................................................................................................................................. 10
When to Estimate (Play Planning Poker) ...................................................................................................... 10
Velocity – “The great equalizer” ....................................................................................................................... 11
Defining “Done” ................................................................................................................................................ 11
Levels of Done ............................................................................................................................................... 11

Agile Scrum Explained Page 1

 Termination of a Sprint ..................................................................................................................................... 11
Sprint Demo ...................................................................................................................................................... 12
Sprint Retrospective – It’s about the TEAM!..................................................................................................... 12
Sprint Retrospective Attributes..................................................................................................................... 12
Sprint or Iteration Planning ................................................................................................................................... 12
Adjusting Priorities ............................................................................................................................................ 12
Determine Target Velocity ................................................................................................................................ 13
Identify a Goal for the Sprint............................................................................................................................. 13
Select User Stories............................................................................................................................................. 13
Two methods of Sprint Planning; ...................................................................................................................... 13
Split User Stories into Tasks .............................................................................................................................. 13
Meetings ........................................................................................................................................................... 14
Bugs vs. Defects................................................................................................................................................. 14
Estimating Tasks ................................................................................................................................................ 14
The right size for a task ..................................................................................................................................... 14
Assigning Tasks / sharing the work ................................................................................................................... 15
Adding a new task to a running Sprint .............................................................................................................. 15
Asking the Team for a Commitment ................................................................................................................. 15

Agile Scrum Explained Page 2

Agile Scrum Explained

Agile Manifesto:

Agile Teams value;

Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Team Focus;
Work collaboratively as one team
Work cross-functionally
Work in short iterations
Deliver something of value each iteration – potentially shippable software
Focus on business priorities – user valued features rather than just isolated tasks
Inspect and adapt

Agile Role Definitions;

Product Owner – The product owner owns the definition of the project, features, business case, etc.
Development Team – The DEV team owns the deliverables; e.g. architects, designers, QA, coders,
testers, documentation, etc.
Scrum Master – Or, Project Manager owns the process and is responsible for removing impediments,
establishing priority for high value functionality, coaching, scrumming, etc.
Everyone else is a chicken! As the story goes….

Agile Scrum Explained Page 3

Agile Planning –
Is planning important? – absolutely!
Is adjusting the plan as knowledge is gained and uncertainty reduced important? – absolutely!

Agile Developers essentially say to product owners: “We will give you a plan based on what we know today;
we will adapt the plan to meet your most critical objective; we will adapt the project and our plans as we both
move forward and learn new information; we expect you to understand what you are asking for.”

Agile is a cycle of Plan-Do-Adapt (repeat).

Planning – “What should we build and by when?” a question to be answered by the TEAM. In Agile this
question is answered iteratively and incrementally.
Good planning process supports:
Reducing risk
Reducing uncertainty
Supporting better decision making
Establishing trust
Conveying information

A good plan is one your stakeholder can use to make business decisions based on. Can your stakeholder plan a
marketing campaign based on your development plan? Does your plan have their trust?
Planning is more important than the plan. Planning is ongoing. The plan itself is going to change. The
knowledge and insight we gain from planning persist long after one plane is torn up and a revised one put in its
place.

Three initial levels of planning:

Release Planning – considers the user stories or themes that will be developed for a new release of a
product or system. The goal of release planning is to determine an appropriate answer to the question
of scope, schedule, and resources for the project. This process is a reflection of the iteration velocity
and is updated throughout the project.
Iteration Planning – is conducted at the start of each new iteration. Based on the work accomplished in
the just-finished iteration, the product owner identifies high-priority work the team should address in
the new iteration.
Daily Planning – or Daily Scrum is the Daily stand up meeting to coordinate work and synchronize daily
efforts. Planning efforts are limited to the next day in this arena.
Note: additional planning levels beyond these are identified as Product Planning, Portfolio Planning,
and Strategy Planning.

Conditions of Satisfaction exist at each level of planning for example at the release level the product owner
will have conditions of satisfaction upon which user stories, budget, and schedule, are balanced and at the
iteration and daily levels acceptance test should be in place for each work item.

Agile Scrum Explained Page 4

 “Delivering small increments of fully working, tested, integrated code”

Scrum Roles and Responsibilities

Development Team
Who is needed to complete the product increment?
o Developers, analysts, designers
o Testers & QA
o Technical writers
o Usability engineers
o Architects
o Product Owners

What are DEV Team Activities?

o Commit to the Sprint
o Own the estimates
o Plan your own work (tasks, dependencies)
o Have the authority to do whatever is needed to meet their commitment
o Rely on the ScrumMaster to help remove obstacles
o Rely on the Product Owner to explain the product backlog items

Product Owners
What is the Product Owner Scrum Process?
o Define value for the product, ROI, Features, Cost, etc.
o Have a vision for the product, its Release, and the Sprints
o Maintain a prioritized backlog of product stories
o Seek guidance from architects, testers, developers
o Show up with the appropriately Product Backlog items
 Epics or large items for release planning
 Smaller items (such as user stories) for Sprint Planning
 Detailed only when items are of the highest priority
o Maintain acceptance criteria for value
o Respect Delivery Team estimates
o Communicate often
o Accept product backlog items as they are completed

Agile Scrum Explained Page 5

What does a Product Owner do?
o Create, maintain and prioritize the product backlog
o Actively participate in release planning
 Communicate release goals
 Present release backlog
o Actively participate in iteration planning
 Present iteration backlog
 Present conditions of satisfaction for each backlog item, story
 Prioritize stories based on their detailed estimates
o Prepare for the next iteration
 Write user stories and their acceptance criteria
 Collaborate with customers to validate user stories
o Attend daily stand-up meetings (daily scrums)
 Visibility into team progress
 Listen during the daily meeting. A product owner is a guest to observe progress
o Validate software delivery
 Review and accept / reject iteration stories

Scrum Master
Responsibilities
o Guards and supports the Scrum process
o Facilitates team decision making and team maturity
 Divergence of ideas leading to informal convergence on decisions
o Removes impediments
o Protects team from external interruptions
o Acts as chief communicator – coordinates communication between team and external
stakeholders, managers, and other corporate communication.
o Controls “no business by favor” (product owners or anyone going directly to a developer with
a special request for a work item.

Differences from the classic Project Manager

o Is NOT the decision maker
o Cannot commit to dates, budgets, etc.
o Facilitates the team and stakeholders to make decisions and meet commitments
o IS A SERVANT LEADER AND FACILITATOR

“Effective self-organizing teams are developed over time”

Agile Scrum Explained Page 6

Scrum Artifacts / Definitions
User Stories
User Story is a brief description of functionality as viewed by a user or customer of the system. User stories
follow this suggested format and answer the question; “As a <type of user>, I want <capability>, so that
<business value>.”

Stories must be written as to be testable. Successfully passing its test proves that a story has been successfully
developed. If the story cannot be tested, how will the developers know they have finished coding it?

Stories must be written in such a way so they can be estimated. It is important for the developers to be able to
accurately estimate the size. There are three common reasons why a story cannot be estimated:
Developers lack of domain knowledge
Developers lack of technical knowledge
The story is too BIG. Large stories can be split into multiple smaller stories.

As much as possible care should be taken to avoid introducing dependencies between stories.

Product Backlog Items

Product Backlog Attributes
o Product Owner “Owns” the Product Backlog. Note: developers own the “Sprint Backlog”
o Product Backlog can be a spreadsheet, a software tool, or a story card.
o Product Backlog items vary in size and detail
o Items for the next sprint are always the next priority items
o Product Owner decides priorities
o The Product Backlog evolves over time
o The Product Backlog is never done
o The Product Backlog is always ready

Product Backlog Includes

o Good descriptions
o Rank / Priority
o Complexity / Cost / Size
o Test, test cases
o Conditions of satisfaction

Sprint Backlog Items

Sprint Backlog Attributes
o Development Team “Owns” the Sprint. Note: product owners own the “Product Backlog”
o Sprint Backlog can be a spreadsheet, a software tool, or a story card.
o Sprint Backlog items are estimated in ideal hours and are the tasks for the sprint
o Development Team selects from the Sprint Backlog the items they will commit to for the sprint

Agile Scrum Explained Page 7

 “Remember not to detail Product Backlog Items until they are valuable for the sprint”

Burn Down Chart

The Burndown Chart is a tool for Tracking Work Remaining, “What is left to do”. The Scrum process does not
focus on tracking the work completed only the work remaining. The process does provide very good
information or reports for your product Owners.

Possible Reporting Metrics;

Current Burndown Chart(s)
Release Burn-up chart
Defects – flow – inflow, outflow, open defects per week, closed defects per week, etc.
Tests – number of test performed per week, number of test passed per week, number of test failed
per week
Velocity – per sprint, over X sprints

ESTIMATING - SIZING (Relative) and Hourly (Ideal Effort) Estimating

SIZING – Product Backlog and User Story levels
o Product Backlog and User Stories are estimated in Relative SIZE
o Story points ask the question, “What is the goal of the item?” not “What is a rough sense of its
complexity?”
o Product Backlog Items are given the “relative size” based on the other item sizes in the
Product backlog.
o The story point value is consistent within the sprint
o The story point value can and likely will vary between teams and between sprints.
o Product Owners “own” the Product Backlog

ESTIMATING – Sprint Backlog or Task level

o Development Team uses “ideal hours” to estimate task
o Use net hours for what capacity and commitment the team can take on.
o Net hours helps manage technical debt or overhead
o Developers are NOT MARRIED TO THEIR ESTIMATES. Estimates are given based on what the
team knows at the time.
o Velocity will make transparent the teams ability to deliver not their estimates.
o Developers “own” the Sprint Backlog

Story Point Estimating is about sitting around discussing stories (gaining shared knowledge) with the team
and the product owner and guestimating the relative story SIZE. Focus on relative sizing, as opposed to
absolute sizing. This should go remarkably quickly. (e.g. 4 is twice as big as 2) After a few iterations the teams
sizing accuracy will improve dramatically and velocity will become transparent.

“Product Backlog Items are given the “relative size” based on the other
item sizes in the same Product Backlog”

Agile Scrum Explained Page 8

Estimating in SIZE (not duration) Story Points are relative. They are a unit of measure for expressing the overall
size of a story, feature, or work item.

The number of story points associated with a story represents the overall SIZE of the story. There is no set
formula for defining the size of a story. Rather, a story-point estimate is an amalgamation of the amount of
effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on.

Story points are not an estimate of the time it takes to implement a feature, even though we often fall into the
trap of thinking of them as such. The amount of time that implementing a feature will take is a function of its
SIZE and a team’s rate of progress is reflected by its VELOCITY.

Here are two common approaches;

The first approach is to select a story that you expect to be one of the smallest stories you’ll work with
and say that story is estimated at one story point.
The second common approach is instead to select a story that seems somewhat medium and give it a
number somewhere in the middle of the range you expect to use.

Estimates are shared and not created by a single individual on the team. Agile teams do not rely on a single
expert to estimate. Estimates are best derived collaboratively by the team, which includes those who do the
work and those who will use the product or the product owner, stakeholders.

First, on an agile team we tend not to know specifically who will perform given task. Remember, the team
owns the deliverable. Second, even though we may expect the database guru to do the work, others may have
something to say about the estimate or it’s’ dependencies.

Estimation of scale; the numbering sequence used is called the Fibonacci sequence which is generated by
taking the sum of the previous two numbers. For example, 0, 1, 2, 3, 5, 8, 13, 21, 34, etc. Each of the numbers
should be thought of as a bucket into which items of the appropriate size are poured. So, a story that you think
is a seven, clearly would not fit in a five point bucket. Why use a zero (0)? Consider the work that is closer to 0
than it is to 1, the team may not want the completion feature to contribute to its velocity calculations. If the
team earns 1 point in this iteration for something that is truly trivial, in the next iteration their velocity will
either drop by one or they may have to earn that point by doing work that may not be as trivial.

User Stories, Epics, and Themes; for features that we’re not sure we want, or for features that may not
happen in the future, it is often desirable to write on much larger user story. A large story is called an Epic. A
group of related stories may also be grouped together and treated as a single entity for either estimating or
release planning. Such a set of stories would be called a Theme.

Deriving an Estimate by three common techniques.

Expert Opinion where a subject matter expert is asked how long something will take and how big it is.
Because on Agile project estimates are assigned to user stories or other user-valued functionality, and
because functionality is likely to require a variety of skills normally performed by more than one
person, this approach is less effective by itself on Agile projects.

Agile Scrum Explained Page 9

 Analogy is what we are doing when we say, “This story is a little bigger than that story.” There is
evidence that we are better at estimating relative size. Estimate each new story against at least two
other previously estimated stories. This is called “triangulation.” A new story being estimated at three
points seems a little bigger than one previously estimated at 2 points and smaller that one estimated
at five.
Dissaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces. Larger
stories are harder to estimate but also there will be few smaller stories to compare. If most of the user
stories to be included in a project are in the range of two to five days of work, it will be difficult to
estimate a single story that may be 100 days. So, you will need to disaggregate the larger stories.

Planning Poker

Planning POKER combines expert opinion, analogy, and disaggregation into an enjoyable approach to
estimation that results in quick but reliable results. Participants in planning poker include all of the developers
on the team. Remember, developer refers to all programmers, testers, database engineers, analysts, user
interaction designers, and so on. The product owner participates in this exercise to answer questions and DOES
NOT ESTIMATE.

Each estimator is given a deck of cards that reads 0, 1, 2, 3, 5, 8, 13, 21, and 34. A moderator reads the story
description. The moderator is usually the product owner, scrum master, or analyst. The product owner
answers all the questions the estimating team may have. However, everyone is asked to remain aware of the
effort/accuracy curve. The goal of planning poker is not to derive an estimate that will withstand all future
scrutiny. (effort/accuracy curve states you can spend too much time in detail to the point of diminishing
returns. Mike Cohn, Agile estimating and planning, pg. 50)

Remember to include all the questions required to meet the product owner’s “conditions of satisfaction” or
It is common for there to be a discrepancy in the first round of poker. Ask more questions. Discover more
information and vote again. You will find that after learning more the second round is often a collaboration
and will look something like 5,5,5,5,3. At this point as the moderator I would ask the 3 if they are ok with the 5
and if so move on. If not we need to discuss the item some more to discover why.

“The two minute timer” is a great tool to use allowing anyone to present their case for two minutes. Once
everyone has had their turn you then vote. This process will often produce the required results.

When to Estimate (Play Planning Poker)

Team will need to play planning poker at two different times. First, during the initial effort to estimate the
large number of items or product backlog before the project officially begins. Estimating an initial set of user
stories in the beginning can take some time and possibly a few meetings. Naturally, this will depend on how
many items there are to estimate, the size of the team, and the product owner’s ability to clarify the
requirements succinctly. Second, the team will need to make the effort to estimate and new stories that will
come forward as the product matures. When should you re-estimate? ONLY when or if the story changes. So,
is this re-estimating or has the story changed so you now need to estimate it again as a new story?

Agile Scrum Explained Page 10

Velocity – “The great equalizer”

Velocity is a measure of the team’s rate of progress. It is calculated by summing the number of story points
assigned to each user story that a team completed during the iteration. If the team completed three stories
each estimated at five story points, their velocity is fifteen for the iteration. Once a team’s velocity is
established usually over the first two or three iterations, it is valuable for future release planning, etc.

Velocity naturally corrects estimation errors as the team begins making progress through the user stories of a
project, their velocity becomes apparent over the first few iterations. For example if the team estimates the
project to include 200 story points of work. They also believe they can complete 25 points per three week
iteration, which means they will complete the project in 8 iterations or 24 weeks. However, once the work
begins they see that their velocity is only 20 points. Without re-estimating any work they are able to correctly
identify that the project will take ten iterations instead of eight.

Note: When a team becomes high-performing with a consistent velocity this becomes an even more important
tool and plays an exciting part in establishing rhythm for the product owner.

Defining “Done”
Without a clear definition of DONE you simply never are…..

Levels of Done
Have you considered defining levels of “done” for the following?

What is “Done “ for a Product Backlog Item?

What is “Done “ for a User Story?
What is “Done “ for a Sprint Backlog item?
What is “Done “ for the Sprint planning meeting?
What is “Done “ for the Sprint?
What is “Done “ for the release plan?
(add your own)

These decisions need to be made by the teams.

Gather the teams and write the “Done Definitions” for each of these items.

Termination of a Sprint
Sprints may be terminated by the team if they feel they are unable to meet the sprint goal
Management or the Product owner can cancel a sprint if external circumstances negate the value of
the sprint goal
If a sprint is abnormally terminated, the next step is to retrospect what happened
Based on that retrospectives finding, conduct a NEW sprint planning meeting, where the reason for
the termination and a revised product backlog is moved into the new sprint

Agile Scrum Explained Page 11

Sprint Demo
Team presents a demo of the completed deliverable product backlog items and/or architecture,
documentation, etc.
Maximum two (2) hour prep time box
Attendees include;
o Team (Developers, Testers, Architects, QA, etc.)
o Scrum Master
o Product owner, Stakeholder(s), Customers
o Any other interested parties, e.g. management, etc.
NO POWERPOINT, a PowerPoint presentation is not a completed deliverable product backlog item.

Sprint Retrospective – It’s about the TEAM!

Team retrospective meetings are for the team. These are special meetings where the team gathers after
completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable
team learning and act as a catalyst for change to generate ACTION. This is more than as simple project close
out or project review. A retrospective does not only focus on the project performance but on the team and
“team issues”. Team issues are as challenging and as important as the technical issues and must be confronted
and resolved.

Sprint Retrospective Attributes

Inspection of the process and team practices at the end of the sprint
Attended ONLY by the delivery team
Facilitated by the Scrum Master
What went well?
What could we have done better?
What actions can we take to improve?
Scrum Master prioritizes improvements based on team direction
Team devises a solution to the high priority problems
Team commits to the solutions
If needed a “Implementation Backlog” is created to rank and track the needed commitments

Sprint or Iteration Planning

With the Sprint or Iteration plan, a team takes a focused, detailed look at what will be necessary to implement
completely ONLY those user stories selected for the new iteration. This is accomplished in a Sprint Planning
meeting. Attending this meeting are the, product owner, analysts, developers, testers, QA, database
engineers, designers, UI designers, architects, etc.

Adjusting Priorities
First, the team collaboratively adjusts the priorities of product backlog or user stories along with any new
stories that may have developed. This may not be the first sprint in the series and the team may need to re-
evaluate the product backlog to re-set priority stories. Business and project conditions change quickly, so it is
always worth a quick reconsideration of priorities.

Agile Scrum Explained Page 12

Determine Target Velocity
The default assumption is that the team’s velocity in the next sprint will equal the velocity of the most recent
sprint. Other teams prefer to use an average over the last three sprints.

Three ways to estimate velocity;

Historical values are great if you both have consistent projects and the data to begin with.
Running a Sprint or iteration is an ideal way to forecast velocity from observing velocity during one to
three iterations. This is the default approach if you can.
Making a forecast involves disaggregating a number of stories into tasks, estimating the tasks, knowing
the team’s ideal hours and forecasting the velocity.

Identify a Goal for the Sprint

With the priorities and the target velocity in mind, the team needs to identify a goal they would like to achieve
during the iteration. The goal succinctly describes what they would like to accomplish during the sprint. The
goal is a unifying statement about what will be accomplished during the sprint. It does not need to be specific
and is probably better if it is not too specific. For example, “Make progress on the reporting functions”. You do
not need to be specific as in “Finish reports, 15, 16, 18.”

Select User Stories

Next, the product owner and the team select the highest priority user story(s) to meet the iteration goal.

Two methods of Sprint Planning;

Commitment Driven Sprint Planning
o The team is asked to add the highest priority stories to the sprint one by one until the can
commit to completing no more. Stories are selected one at a time because after each story is
split into tasks and estimated, the team decides whether or not they can commit to delivering
that story during the sprint.
Velocity Driven Planning
o As many stories are selected as necessary for the sum of their story point estimates to equal
the target velocity for the sprint. Then each story is split into tasks, and each task is estimated
into ideal hours. The team then will determine whether they can commit to a set of user
stories by summing up the estimates given to the tasks and see if the total represents a
reasonable amount of work for the sprint.

Split User Stories into Tasks

Once the appropriate set of user stories has been selected, each is decompressed into the set of tasks to
deliver the new functionality. (depending on the planning method selected, e.g. committed or velocity driven)

ALL TASKS necessary to go from a user story to a functioning, finished product MUST be identified. Writing the
acceptance test cases, fixing bugs, or automated unit test are all tasks within the sprint. If there are analysis,
design, UI design, they are to be identified and estimated. The goal of each sprint is to produce potentially
shippable product, take care to include tasks for testing and documenting the product. Including test in
critically important because the team needs to think right from the start about how a user story will be tested.

Agile Scrum Explained Page 13

Be Specific to identify and estimate unit test explicitly. A developer may identify a feature will take eight hours
and that writing its unit tests will take an additional five hours. The total estimate for this task is then thirteen
hours. However, you may want to identify it as two tasks one being the programming and the other being the
unit tests. Once the team is confident the tests are being written and performed they may want to combine
both tasks back into one.

Meetings
You should identify, estimate, and include tasks for meetings related to developing the project. If you know
three developers will need to meet with the architect for 2 hours then you can estimate the task at eight
hours.

Bugs vs. Defects

The team has the goal of fixing all bugs in the sprint in which they are discovered. They must become proficient
while working in short iterations in cleaning up technical debt and bugs during the sprint through relying on
unit and automated testing. When a developer gives an estimate for coding something, that estimate includes
time for fixing bugs found in the implementation, or a separate task is identified for “correcting bugs.”

A defect found later or not fixed within the sprint in which it was discovered is treated the same way as a user
story. Fixing the defect will need to be prioritized into subsequent sprints in the same way that any other user
story would be. Outside of a sprint, the whole idea of a defect starts to go away. Fixing a bug and adding a
feature become two ways of describing the same thing.

Estimating Tasks
Some teams prefer to estimate tasks after all have been identified; other teams prefer to estimate each task as
it is identified. Tasks estimates are expressed in ideal time like “6 hours” even if I know 6 hours is going to take
all day. Tasks on a team should be estimated by the team. Estimating tasks is a team endeavor. Here are four
reasons;

Tasks are not allocated to a specific person during sprint planning. One person is not responsible for
the task.
Even though one person may be expected to do a task, and even though they may know the most
about that task, it does not mean that others do not have something to contribute.
Hearing how long something will take often helps teams identify misunderstandings about a user story
or task.
When the person who will do the work controls the estimate the person’s pride or ego may influence
the estimate.

The right size for a task

The task you create should be of an approximate size so that each developer is able to finish an average one
per day. Tasks larger than this tend to involve more than one developer and the rest of the team can be left
waiting for them to complete their task. What’s great about this is that for teams holding daily scrums, having
tasks of this size allows each developer to report the completion of at least one task on most days.

Agile Scrum Explained Page 14

More importantly, having smaller tasks will allow it to quickly become transparent when the opportunity arises
for one developer to help another. This will also assist the Scrum Master to see when a developer may need
the assistance of someone else on the team and encourage collaboration.

Assigning Tasks / sharing the work

Tasks are NOT allocated to specific individuals during the Sprint planning meeting. It may appear obvious who
will work on a specific task; however, what is obvious at the start may not be what happens during the sprint.
Projects do best when they foster a “we’re all in this together” attitude. When team members pick up the slack
for each other knowing that the favor will be returned you are on your way to becoming a high performing
team. The tasks for a Sprint are estimated in ideal hours. Individuals do not sign up for tasks until the iteration
begins and generally sign up for only one or two related tasks at a time. Once the tasks are identified and
estimated and the sprint is ready to begin the team members select and commit to their tasks for the sprint.
Not all tasks have to be assigned it is a team effort based on the ideal hours of the team. Remember, the team
selects their work. It is not assigned to them.

Adding a new task to a running Sprint

If and/or when new tasks for a story are discovered during the sprint a team that is committed to delivering
the functionality described by that user story will try to complete the new tasks in order to complete the story.
Caution; the team will likely need to discuss the situation with the Scrum Master and the Product Owner and
see if there is still a way to meet the sprint goal or will they need to reduce the functionality of the story or
drop one entirely.

Asking the Team for a Commitment

What’s the question? The question is “Can you commit to delivering the features we’ve discussed?” notice the
question is NOT, “Can you commit to delivering the tasks we’ve identified?” Why? The second is a much
weaker question and one we are not interested in. We are however interested in delivering shippable product
at the end of the sprint. The team is committing to delivering the functionality described by the user story.

Agile Scrum Explained – This document is a compilation of proven training ideas from some of the leading Agile
minds. References; Mike Cohn - Agile Estimating and Planning; Agile University; Mike Cohn - User Stories
Applied; Jean Tabaka - Collaboration Explained;

Agile Scrum Explained Page 15