5 Simple Steps for Setting up a new Agile Scrum Team

Where do we start? How do I know if the team is ready to start Sprinting? Is there a new Agile Scrum
Team set-up checklist? Does this sound familiar to you? They are the questions I faced when first
starting Agile Scrum coaching. With over 25 years of training and consulting specializing in
implementing and optimizing project management processes and tools, I was used to a checklist. The
PMBoK was a great checklist as it contains 10 knowledge areas, 5 Process Group, and 49 processes.
Wait the Agile manifesto states that we value individuals and interaction over processes and tools.
Principle 12 indicates Simplicity--the art of maximizing the amount of work not done--is essential. As
a result, I was told there are not any processes, checklists or tools just be Agile. My 25 plus years of
consulting with over 200 clients worldwide told me “That dog don’t hunt”. So, I built my own 5 Simple
Steps for Setting up a new Agile Scrum Team, which I will share with you in this whitepaper.

Okay, there is a lot on that one chart for the rest of this paper let’s look at the inputs, and outputs
associated with each step.

1
The team should have attended Agile Scrum training, but if all members a relatively green engaging an
experienced Agile coach will be well worth it to help your team avoid common pitfalls. One of the first
things your coach should do is ask to see the product vision, epic roadmap,
and problem definition. They may not exist, so defining this is a logical
starting point. If they do exist an interesting exercise is to get each team
member to write the Vision and Problem statement on a sticky note if you
have 10 team member and each person has a different vision and problem
statement You have a problem

Asses the Scum Master who should be a Certified Scrum Master and the
Product Owner who must have the authority to prioritize the product
backlog item (PBI) and truly have the knowledge to be the “Voice of the
Customer. Next access the team. Hopefully, you have a cross-function,
self-organized, trained, and motivated people. Caution the team, Scrum
Master, and Product Owner may have none of the aforementioned, and Training will be required.

After step 1 you should have your Vision, Road map, Problem statement, trained Scrum Master,
Product Owner, and core team members. In addition, you will have defined the team's capacity and
obtained Sponsor approval to proceed.

Do have multiple applications like SharePoint, JIRA, Microsoft Azure DevOps (ADO), Slack, Teams, Outlook,
Trello, and more. If you answered yes two or more you may end up with “Where is it”, “I can’t find it”,
and after an hour of checking emails, SharePoint, Teams the questions remain unanswered. Step 2 is
simple, but it is very important to define in a team agreement which tools are used for what purpose. For
example, with several teams, I have recommended that discussions, issues about a User Story or Product
Backlog Item (PBI) are documented on the PBI’s card in Microsoft Azure DevOps (ADO). Since SharePoint
has version control capabilities I have recommended that documents get uploaded to a SharePoint
document library and link to the document is on the associated PBI card in ADO. Because most teams
comfortable using Outlook for scheduling meetings I recommend that the Sprint events be scheduled in

2
Outlook, but I stress not to use Outlook for discussing Stories or to share documents. Lastly, if a team has
tools like Slack or Teams, I suggest they use these applications to quick questions and answer with team
members that are not collocated.

The SharePoint site will require configuration to structure the document library as will Microsoft ADO to
work with your Kanban workflow and to set up your product backlog. Just because the tools are relatively
simple do not assume that all team members know who to use the applications, so plan to do some tools
training. If you have completed a unique configuration all team members should be trained.

The output of Step 2 is that you have defined which application to use for what purpose, applications
and have been configured and your team has been trained on how to use each tool.

The Product Backlog is a list of items (e.g. Epics, Features, User Stories, Technical Stories) prioritized by
business value. Detailed requirements in the backlog should be written as user stories. User story format:
As a <user role> (WHO), I want to <achieve some goal> (WHAT) so that I can <receive some benefit>
(WHY). We all know about GIGO or Garbage In Garbage Out! An absent or inexperienced Product owner
coupled with a poor; Product Backlog will result in garbage out.

The focus of the Backlog Refinement is on prioritized stories that are targeted for the next 1-2 sprints.
During the backlog refinement the team:

– Discusses new stories and acceptance criteria

– Seeks to understand requirements
– Understands what is needed to demonstrate the story
– Size new and upcoming stories
– Splits Stories into smaller stories if appropriate
– Identifies dependencies
– Leaves session with action items to resolve issues to be ready for Sprint Planning

3
Step three involves hard work to ensure that 2 Sprints' worth of product backlog items meets the team's
Definition of Ready (DoR). Having a DoR will help to ensure that Product Backlog Items will be ready before
they are discussed in the Sprint Planning Meeting. Your DoR must be an agreement between all team
members of what it means for a Product Backlog Item to be 'Ready’. The following is an example of a
Teams Definition of Ready:

• Each PBI user story has a clearly defined user

• The Business Value is clearly articulated

• All stories must meet the I.N.V.E.S.T. criteria

Independent
Make Stories as independent from each other as possible
Negotiable
Brief description. Details emerge in the discussion
Valuable to users or customers
Users and customers perceive value in the deliverables
Estimateable
Domain, technical knowledge allows the Team to provide an estimate
Small
The team can finish one Story in a few days, several in one Sprint
Testable
– Validation criteria and techniques are specified clearly
• Details are sufficiently understood by the development team, so it can make an informed
decision as to whether it can be complete the PBI item in a sprint

• The PBI is estimated and small enough to comfortably be completed in one sprint

• Each PBI has Acceptance Criteria which is clear and testable

• Performance criteria, if any are defined and testable

• The scrum team understand how to demonstrate the PBI at the Sprint Review

After step 3 you will have a clean backlog, trained team and you are ready to start Sprinting in Step 4.

4
You already have a DOR and a clean
backlog but before you start Sprinting
Define explicit criteria for “Definition of
Done” (DoD). All stories are is not Done
until all criteria are met! The DoD has two
parts

1. Policies about how to test and

validate deliverables

2. Checklist of required tasks that reflect

organizational standards

DoD is not the same as acceptance

criteria as Acceptance criteria are
about specific characteristics of a deliverable and DoD is about policies that apply across
deliverables.

Each event needs to be scheduled and run for 1-to 3 sprints. This chart provides a duration, input,
output, and value which will help you in scheduling your event. Don’t short-change or skip an event,
my last whitepaper “ Stuff Rolls Down Hill “ defined the consequences of skipping and shorting
events.

After step 4 your team should be comfortable with each event and using the applications. Each Sprint
ended with a retrospective and the lesson learned were applied to result in improvements from Sprint 1
to 3, but since this is a new team you should move to step 5 and conduct an Inspection and Adaptation.

5
 • Step 5 is like a Sprint retrospective where you
examine what is working and not working. The output of this effort may be a backlog
refinement, adding, subtracting, or changing team members, the further configuration of your
application, and the elimination of non-value-added tasks. We leverage Disciplined Agile Guided
Continuous Improvement to solve the team’s problems and to Address Challenges in any Agile
environment

Summary

Here is the graph that summarizes all 5 steps

I do hope that this has been valuable not only for those of you that are going to set up a new Agile team
but if you are currently Sprinting and steps 1-4 were incomplete take a step back and complete these
steps. Perhaps you might want to focus your next sprint on doing the missed steps, versus continuing to
pull PBI’s from the backlog.

6
 Keith Wilson,

MBA, B.Comm., PMP, MCP, MCT, CSM, CSPO, SPC, CDAI, CDAC, DASSM

KWilson@at-llc.com
Keith Wilson’s background includes over 25 years of successful
coaching, training, management, and consulting experience. He is a
welcomed facilitator at numerous fortune 500 corporations, universities, and
associations worldwide and is well known for his public speaking skills and enthusiasm.
He has successfully consulted, developed courses for, and coached and trained
thousands of people worldwide virtually, in person and through on-demand recordings
in all areas of Agile Scrum, Kanban, SAFe and Disciplined, Project, Program and Portfolio
Management, Business Analysis, Microsoft Project, Project Online/Server, SharePoint,
Microsoft Azure DevOps, Leadership and Interpersonal skills. Keith is consistently rated
as a top coach, trainer, and facilitator with outstanding evaluations and comments that
include: Very Engaging, Energetic, Entertaining, Informative, Over The Top
Interesting, Great Presenter, Very Enthusiastic; Humorous, Clear, Concise and
Effective, Extremely Knowledgeable, The Best trainer I have had in 30 years.

For more details, feel free to contact Keith Wilson at:

kwilson@at-llc.com

https://www.linkedin.com/in/keith-wilson-6604806/

https://www.agile-transformational.com