This blog is created in effort of explaining all major aspect of scrum process. The process is divided into 12 steps, which are explained below.

Complete_full_picture

Steps 1 & 2: User Story Writing and Estimation

step1-2

User stories are user requirements in the plain customer’s language without including too many details. Usually User stories are written in following format.

As a <User> I want to <Perform a function> to <achieve something>

In agile world you start with writing user stories, sometimes in a special user story session. Since stories are written from the customer’s point of view so participation of customer and sponsor are required, at the same time representative of development team are also encouraged to be part of the workshop. Having development team on the board sometimes help non- technical team members, to reduce number of stories, and help development team to understand the requirements at the early stage of the project.

In user-story writing sessions everyone who can contribute should be invited. A great story-writing workshop is full of discussions and brainstorming.

Some of the user stories can be huge, and could be divided into many smaller user stories; those big user stories are also called “Epics” or “Features”. One Epic or Feature can have many smaller user stories.

To make a user-story more understandable more details or extra documents can be added with it.

Participant: Product Owner, Stakeholders and Dev. Team

Purpose: To write down the requirements coming directly from customers without any technical jargon.

When: Usually performed at the beginning of the project and repeated after every release but could be performed whenever need to be performed and not restricted by time.

Types: User Stories, Features, Epics and Themes.

Example: As an admin of my website I want to have a secure website so only authorize people could access it.

Story Estimation

step2

Once story is completed, it needs to be estimated, in a session with the help of the team. Participants of the story estimation team are development team members and product owner. Presence of development team is important since they can provide good feedback regarding design, development and testing activities. Product owner presence is also important because of his knowledge of business.

Story points: Story points are used as unit of estimation in agile world. Sometimes teams assigned a time frame to story point to get exact idea how much time it will take to complete the story. Sometimes team select the hours instead of story point though it's not preferred estimation unit.

The question is why we want to estimate the stories, the simple answer to this question is “to know how long would it take to complete them”, knowing the estimate is important to get an idea how many user stories can be completed within one Release.

There are different ways of estimating user stories such as following sequence where each term is found by multiplying the previous term by 2.

1, 2, 4, 8, 16, 32, 64, 128…

In this technique teams set a small standard story and assign it the number 1, all other stories are compared with this initial story, if another story requires twice as much effort as compare to initial story then it will assign 2, if it requires 4 times efforts than story then 4 will be assigned to it.

Planning Poker:

The Planning poker is another very famous method used to estimate user-stories. In this method each participant holds a card with values of 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. User story is read in the meeting and all the participants display a number showing the effort required to complete it. If everyone displays same number then that number is accepted as an estimate otherwise difference of numbers can initiate some discussion to understand why different participant think different effort is required. After discussion same process teams again show the cards with number, once a consensus is established team moves to next story, and same process is repeated for all the stories.

Steps 3 & 4: Story Prioritization in the backlog

step3

Only a set of stories are selected to be implemented in iteration. To select the stories for iteration, team prioritizes them based on their importance, need and risk value. For example in the start of the project user stories which are related to design will take precedence over development related user-stories. Usually higher risk stories are also of highest priority ones.

Out of iteration stories can be prioritized and re-prioritize when needed inside the product backlog, but once added to the iteration (sprint) adding or replacing user-stories with the existing ones is not recommended.

There are couple of famous techniques used to prioritize the user stories. One of them is called MoSCoW (Must Should Could Won't) technique. In this method user story’s priority is defined by words 'must', 'should', 'could' and 'won’t'.

Another way of prioritizing is to assign simple numbers to stories, story with lowest number has the highest priority, and story with highest number has lowest priority in the backlog.

Step 5: Release Planning

step5

A release is a time-boxed activity in which certain high ranked user stories are set to be completed. A release planning meeting is arranged so team could see what product owner and stakeholders want to achieve in a specific time. And also gets chance to look into the vision and road map for the product. This meeting helps everyone in the team to come on the same page. Stakeholders and product owner transfer their vision and expectation to the development team. Development team contributes in refining the concept of the project by asking more questions and in some cases providing the answers of the unknowns given by product owner or come up as a result of the discussions.

Velocity

Velocity is an important factor in deciding how many ranked user stories can be completed in a given time. It is counted in the unit of story points, and gives product team an idea about the capacity of the development team. If a product owner wants 20 user stories to be part of the release and each user story has 5 story points then 100 is the total number of story points need to be completed in a release.

If team’s Velocity is 33 story points per iteration then team can complete a release within 3 iterations. In the early releases team’s velocity is not stable and predictable. It usually takes 3 iterations to find the velocity of a team.

Step 6 & 7: Sprint Planning & Task Creation Process

steps6-7

The Sprint planning meeting takes place in the beginning of iteration. The development team selects a higher priority user story and divides it into one or many tasks. Tasks are created and assigned by developers.

Same process is repeated for all the stories until capacity of the team is reached. Once capacity is reached no more user stories are added. During the process of dividing the user stories into task, everyone in the development team collaborate and give his/her estimate to complete a task, planning poker technique can be used for that purpose. Team identifies the work to perform and commits to delivering potential product increment at the end of iteration.

Step 8-12: Sprint Iteration

steps8-12

Development team works on design, development and testing activities during an iteration (sprint). Duration of a sprint varies from team to team. 1-4 weeks iteration can be selected but mostly 2 week iteration is popular in agile.

Step 8-12 shows sprint and activities performed during and at the end of a sprint. At the end of each sprint product output is produced and demonstrated to the customer in Sprint Review meeting. Also at the end of each sprint retrospective is performed to review the scrum process within scrum team.

A release may consist of many sprints. Release output is a product that can be used by the customer.

Click here to learn more about daily scrum and other scrum meetings.