Well, I think we already realized that scrum can be used almost for any
project anywhere…
So here is a short scrum framework technical description that those,
‘Non IT’ guys may use as well.
‘Scrum' Is an Innovative Approach to Getting Work Done:
Scrum is an
agile framework for completing complex projects. Scrum originally was
formalized for software development projects, but works well for any complex,
innovative scope of work. The possibilities are endless. The Scrum
framework is deceptively simple.’
Scrum is based on the following
main principles:
- Interactive and
incremental process.
- Team self
organized based approach.
- Adapting to change.
- Cooperation and
communication is key.
- Adapting and
following the Agile manifesto and principles
The Scrum framework in a nutshell:
A generic Scrum framework looks like this:
Backlog: The wish list that includes all the
things we need to do, ordered by value for top 5-10 only
Sprint backlog: All those
things we wish to do in the immediate next execution time frame (sprint) ,
ordered by value, divided to operative tasks ,and estimated/sized.
The sprint – A fixed time
fame, with a beginning point and an end point , I which we execute the backlog tasks
and commit for a quality of delivery.
Ceremonies:
Sprint starts with a planning
session: The backlog items are sized, divided to tasks, estimated and the
scrum team commits for their delivery.
Sprint daily meeting to
evaluate progress and commitment
Sprint Demo: At the end
of each sprint the team presents the sprint outcomes and deliveravles.
Sprint retrospective meeting At the end
of each sprint , the team will retrospect over their performance for continues improvement.
Scrum holds three main roles:
- Scrum Team: responsible for deliver
- Product owner: leads the production way, Responsible for return on investment.
- Scrum master: facilitate the process
The roles of a scrum framework :
A Pig and a Chicken are walking down the road. The Chicken says,
"Hey Pig, I was thinking we should open a restaurant!". Pig replies,
"Hm, maybe, what would we call it?". The Chicken responds, "How
about 'ham-n-eggs'?"
The Pig thinks for a moment and says, "No thanks. I'd be
committed, but you'd only be involved!"
This story represents two types of team members in the Scrum framework.
Pigs, who are totally committed to the project and accountable for its outcome,
and chickens, who consult on the project and are informed of its progress. Chickens
are usually management, project managers and others that are not part of the
team. Pigs are the actual team members, who do the actual work.
Pigs can have actual tasks on the task board . The project manager needs
to make sure there are enough pigs to perform the job and they are empowered to
make decisions. For instance, pigs get priority in the Scrum ceremonies. He is
the only one that can talk in the daily session and estimate tasks during the
planning. The chickens are only there to challenge him to do so , teach him how
to do it, and keep him safe so he can perform and deliver.
The Scrum framework is built from different roles that make sure the
framework stands.
The scrum team: self organized team Multi skilled,
responsible for the delivery of a working product at the end of every sprint.
It manage its own tasks, estimate its own tasks and strategies the sprint so a
delivery will be possible. The team best format will be up of 3–9 people with
cross-functional skills who do the actual work. They are the pigs.
Product Owner:
the product owner is responsible for the return of investment. He
represents the “customer voice” (it does not need to be a physical customer) - creates
and prioritized the wish list called backlog.
He leads the way, decides on what needs to be done and accept the stories.
Each scrum team should have one Product Owner; it is recommended that
this role not be combined with that of Scrum Master or the team manager.
The Product owner defines the backlog , is responsible for writing the
user stories (but does not need to write them himself) , accept stories, and
the sprint demo is for him. For most cases he is a chicken. Meaning, he comes
to the daily session, listen and save his questions till the end.
The product owner is expected to be involved, give and get early
feedback and accompany the team with feedback.
Scrum Master : one of the team members, responsible to facilitate
the process. The scrum master knows Agile, enforces the rules, and leads
the team towards the agile mindset. The SM is accountable for removing
impediments to the ability of the team to deliver the sprint goal/deliverable.
He is not the official team leader but should be a leader in any actions and term.
Manager : He is responsible for the vision. He is an
empowering manager and empowers the team to make decisions. The manager is
responsible for making sure the team performance fits the organization vision.
He is not part of the scrum team. He is a chicken.
Let’s go over the process:
We start with a wish list (the backlog):
Basically, the wish list contains all the tasks that the team
needs to do - the task pool. This pool is decided by the business. What do I
mean?
If it’s a software project, the backlog will include
everything the development team needs to do to successfully complete the
project, such as developing new features, new reports, and so on.
In our home, the backlog can include all the things we as a
family need to do, such as tidy up the shed, mow the lawn, pay the mortgage,
and so on.
Let’s imagine a team of school teachers. The wish list will
include tasks set by the Board of Education, and tasks that we think are
important, such as Parents day, an active recess, and so on.
The backlog, in it’s initial form, can be very general. It
can be a list of all those things that we want to happen. We don’t need to go
into great detail. For example, the school teachers’ backlog can include fundraising
for the petting zoo and fundraising for extra tuition. Both these needs will be
added at this stage, even though it isn’t clear which is more important, and
how we’re going to do it.
High level ordering our backlog:
Like any personal or software project, we have a lot of things to do. Let’s
take a wedding for example. You need to set the date, food, guests, seating
arrangements, and more. We know that detailed planning for six months won’t
work. For instance, what is the use of planning seating arrangements when you
don’t even know who’s coming and where the wedding will take place. We DO know
what our high level building blocks are.
Our backlog should be ordered in such a way that we can distinguish
between what needs to be dealt with first, and what afterwards. At this stage,
we can understand the value behind each task we need to perform, so that we can
put them in the right order for the business.
The order of the tasks can be determined by a number of factors, among
them the importance of the task, how difficult it is to carry out, how long it
will take, and more.
We don’t have to drill down to specific details, yet. We
just need to know ‘enough’ about the issue to add it.
Now would be a good idea to think about the relative ‘size’ of each
task. Is it a big one, a medium one or a small one?
User stories:
This backlog is then divided into smaller portions, in a process
of continuous planning. Don’t forget to do this only with the most important items
in your backlog.
User Stories will be created to identify small practical
“can do” items. The user stories are a description of a task we need to do, along
with a definition
of ‘Done’, so the team will know what is expected from them to achieve, be
able to estimate and then commit to the achievement of a specific user story or
a bunch of user stories.
Each user story will be written in a way that the team will understand
its definition of done, and will be considered done when the conditions are
met.
Take the wedding for example – We want our DJ to have good references
from other weddings – when that happens, the user story is marked as ‘Done’.
The sprint :
The team is given a time frame, called “sprint”. This timeframe is
two to six weeks long, and is fixed. It has a beginning and an end and includes
all those user stories the team is committed to deliver at the need of it.
The team will select and commit to a number of user stories for
delivery during the sprint.
At the beginning of each sprint, the team will hold a planning
session. In this session, the user stories will be presented to the team along
with the sprint outcome vision.
The team will estimate each user story and divide each user story to
operative tasks.
The team will discuss their strategy to deliver all the user stories
for the end of the sprint.
For example, our teachers’ parents day, can have a task to contact each
class parents’ representative and present the ideas. Another task may be to set
the date or to collect only feedbacks depends on the definition of done, as
decided by the team.
The team then will commit to deliver these completed tasks.
The task board:
The idea is to be able to look at the entire task pool, and
organize them in one place that everyone can see - the ‘Task Board’. Now
take ALL those tasks, and stick them on the task board each related to a
relevant user story. Placing them on the task board means that you are paying
attention to them, and you will get to them.
The task board will visualize the way a user story related
task need to go from being defined, to being ‘in progresses’ until it’s done. The team will move tasks along the board to
visualize their current state.
Usually this task board holds three main phases: To-do , In
progress, Done.
Once a day, the team will hold a daily Scrum meeting in front of the
task board and answer three questions.
- What did I do
yesterday?
- What am I going to
do today?
- Is there anything impeding
my progress?
The team will make sure their commitment is on track and if not, the
team will handle the impediment and the solution.
The daily standup meeting lasts no more than 15 minutes.
During the sprint, each team member works on one task at a time,
depending on their capabilities, completing those tasks one after another. Once
all tasks are completed, the user story related to those tasks can then be
accepted.
Acceptance = The user story answers the Definition of Done. Each completed user story will be accepted,
meaning, reviewed by the ‘customer representative’ and approved.
End of sprint :
Finally: At the end of every sprint, there should be deliverable user
stories, preferably all of them.
Keep in mind, it’s better to have 80% done stories then 100% started
stories.
Demo session: At the end of each sprint, the team will conduct a
review/ demo session where they will present the sprint outcome: the team will
review their sprint vision, summarize their sprint achievement and present the
main artifacts to their stake holders.
Retrospective session: The team will retrospect their
performance as part of the continuous improvement process. They will then
analyze things they wish to continue doing, things they need stop doing and things
they will start doing, and add two or three action items that will become tasks
on the board for the next sprint.
This cycle of delivery continues.
To sum this up : now it is your turn :
The beginning:
- Define the roles. : Product owner, Scrum
master and the Team.
Before the sprint:
- Create your building block wish list.
- Order a high level priority according
to the value expected.
- Understand the high level sizing
of each building block.
- Divide big building blocks into
operative user stories of 3-5 days effort t estimation max.
The sprint
- Conduct a planning session, estimate
each US and divide to smaller operative tasks. days effort max.
- Conduct a sprint planning
session with all the team at the beginning of the sprint.
- Present the sprint vision.
- Ask the team to estimate
each US.
- Divide US into smaller
operative tasks.
- The team will plan their
strategy to achieve those US towards deliver.
- The team will commit.
- Visualize your sprint tasks and
US on the task board
- During the sprint move tasks
along the task board according to their actual progress state.
- Conduct a daily scrum meeting.
- Accept finished user stories.
End of sprint
- Demo the sprint artifacts and outcomes.
- Conduct a retrospective meeting.
References:
