?Scrum for everyone! What is scrum In a nutshell

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.

As ScrumAlliance says,

‘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:

1. Interactive and incremental process.
2. Team self organized based approach.
3. Adapting to change.
4. Cooperation and communication is key.
5. Adapting and following the Agile manifesto and principles

Scrum is one of the Agile practices, based on implementing 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  :

Let’s start with the Chicken and Pig story:

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:

• As ScrumAlliance
• Chicken and Pig
• C. P. PURI (2009), Agile Management: Feature Driven Development, Global India Publications
• http://www.irontrybe.com/forum/archive/index.php/t-60332.html
• Leachisms: Quotes From the Pirate King. http://bleacherreport.com/articles/78729-leachisms-quotes-from-the-pirate-king