Agile Scrum - How to play

Agile Scrum - Enjoyable and productive

Agile Scrum is a great way to manage your task within a project.
Agile Scrum provides a burndown chart which keeps you on track of how much task you have completed in a graph format, and what is left remaining.

Agile Scrum should be also be flexible. For example, if estimating a task deadline, it's not always going to be accurate, but some thought should be put into the deadline. Also, for the experienced developers, we all know that our clients would 99% of the time would want some sort of change requirement to a task or a section of a project, especially if it's a huge project. Agile Scrum should adopt to some change requirements if required.

So let's start of how to play Agile Scrum.

First thing we should ask ourselves is what we need to play Agile Scrum.


So here's the main things required for Agile Scrum

1. We obviously need our developers referred as team members

2. It is recommmended to have a scrum master. Someone who monitors and keeps track of how the task is progressing in the project, and any hurdles in the way.
Generally, it is the scrum master who either always develops the burndown chart, or then either tightly monitors the burndown chart.

3. Project Manager, who mainly interacts with the scrum master.

4. White board is required for managing stories and task.

5. Each team member, and possibly scrum master is required 10 cards or papers, numbering from 1 to 10. This will be used to vote to see how much importance is required for each story, and possibly how long it would take to develop.

6. Some sticky papers (post-it note) to be used as stories to be put on the white boards.

7. It is handy to have a task management tool, such as Jira Agile Scrum project to manage Sprint Runs.

8. Each team member is a player, so like monopoly having difference characters for each player, each player should be identified as a unique character.


How to play

1. Identifying each story and sub-task

Each feature or a huge task is known as a story.
And a story can consist of many sub-task or sub-story.

First thing required is the break up the project into features (or stories).
For example, if developing a blog website, then "post" can be a feature, and "comments" could be another feature. Post can be divided into more features or stories, such as "send notifications", "verify post or approval process to approve post", etc.

We should also identify which story are required before another.
For example, "post" is required before "comments", as comments without a post does not make sense.


2. Specify sprint runs and how long should they be

sprint runs can be 1 week, or 2 weeks or 1 month.

So for example, if we have specified sprint runs to be weekly. For the first week, we will put all our story and sub-task required for that first week.
Before doing this ofcourse, we should be realastic of how many hours (or time) we can put in development each week, or we can specify how many points we can do for each week.
The difference between points and time will be explained later on below.
So for example if we have 3-4 developers, then possibly 120 points might sound fair.

Points vs Time
Time is how much hours we put into a task. For example, we might put in 4 hours of work to a specific story. Therefore we might give 3 points for that task.
Points refer to how much importance that task is. So for example, we might deploy a sql script to specific live database which might take 1 hour. But because live environment is so sensative, we might still assign it 3 points (to test if everything is working, etc.)

3.  Placing stories on the white board

Stories can be put on the sticky paper or post-it notes with the text such as, "approval process for post approval". Then all stories are to be placed on the white board in a horizontal straight line.
If we have too many stories, then put atleast all the stories for that week on the white board.
Specify each sub task for a specific story, and place that vertically beneath each story.


4. Voting and assigning stories to each team member

Now that the stories and sub-task are all on the white board, each team member and scrum master should vote on how much point each story requires.
Also, each story or sub-task should also be assigned to specific character (team member), and put that character over the story sticky paper, to easiliy identify, which story or sub-task is assigned to which character.


5. Starting the sprint run

Start the sprint run for that week (meaning start developing the sub-task or story for that week). Scrum master should be monitoring the process of the sprint run and if required, interact with the project manager to keep the project manager in the loop.


6. Retrospective meeting after the sprint run

After each sprint run, a retrospective meeting is for all team members and scrum master.
In the retrospective team members and scrum master can identify the strengths and weaknesses for that sprint run, and how to improve future sprint runs.


7. Iteration process and burndown chart

Specify the story and task required for next sprint run, then repeat steps 4 to step 6 as a continous iteration process until the project is finishes. In the meantime, the Scrum Master should be developing the burndown chart for each scrum run.

Here some more details of the burndown chart.

http://en.wikipedia.org/wiki/Burn_down_chart