Improve Your Technology

Just another blog for techology

ABC of Scrum: Practice

I think you got some idea about Scrum. Now it’s time to practice in terms of work. In this blog I am going to discuss about few things

  • Product back log
  • Priorities
  • User stories
  • Velocity of team
  • Working on stories
  • Work burn chart
  • Requirement changes
  • Common questions

 Product Back Log

Product back log is the place to maintain all requirements. Product back log contain user stories. Normally requirements are collected from clients and end users and then analyses the requirements. Then from those requirements user stories will be written based understanding. A user story can be combination one or more requirements. The reason for writing user story is to understand the requirement s and putting in right way. After having user stories, the product owner will put priorities based on the client needs and ROI.


Priority defines the importance of the user story. There might be less priority in terms of developer but it might add more business value, so the priority will be set by product owner who has good idea about the product or project. Based on these priorities the sprint team can review the next coming stories before sprint planning starts.

The change in priority of the stories will impact next coming sprint not the current running sprint. But product owner has a right to terminate existing sprint for high risk and business value items (Story point).

User Stories

A user story is nothing but requirement. Anyone can add user story to back log, it will be reviewed by product owner for priority and he also compare with other existing stories for better product back log. In normal scenarios the product owner reviews client needs and splits all needs into smaller requirements, these requirements will be treated as user stories (Story Point). Sometimes these user stories contain requirements in terms of use cases.

Splitting of user requirements into user stories, will be responsible for product owner and client. In this process analysis and design teams will be included. The design team will look at high level design, like architectural design and modularization of entire project. Analysis team will look at understanding needs and they will provide proper inputs to the design team for better decomposition of the product. Based on these things entire project/product will be split into smaller components or user stories. Some time a single user story takes more than one sprint and some times more than one story will be covered in a single sprint. So creating a user story never looks at time span. It gives freedom to high level team who involved in writing stories, for providing requirements in better manner.

Velocity of the Team

Velocity of the team defines how much work a team can do. Scrum practice velocity will be measured based on no of stories covered in a set of sprints. Based on previous sprints it will be measured. Velocity contains number of developers and time availability and their skills. If one team member removing from a sprint will result in a huge change in velocity some time there won’t be any change and some time it increases the team velocity. It completely depends on the team member. So Velocity of the team never depends on the team count.

For finding team velocity, we need to do experiment. We have to ask team how many stories they can take in this sprint. Based on their comfort product owner will assign user stories. Product owner never force team to take more stories. Why because team will know better than product owner how much they can do. Scrum is a time boxed process, we are not going to extend these times once sprint started. So product owner trust the team and allots the stories.

Working on stories

Once user stories assigned to the team, its team responsibility to split the each user story in to set of tasks and share among the team. In the team also no one is going to assign work to other and no one force other to take the task. It is each team member responsibility to select their task from the list. In this process sometimes we see people are looking at easy tasks. So as a team, team has to decide how to distribute work among the team. It is completely scrum master responsibility to make sure that ever one understood the requirements and are ready to work.

How can we resolve the problem between skilled person and normal persons? A skilled person will do more work than normal person, so in order to resolve this problem; team member can ask skilled person to work on complex tasks and normal person to work on simple or medium tasks. If we do this for each sprint then we face more problems and it will result disputes in the team and final result will be team failure. To solve this problem, scrum master has to provide training session to normal skilled person to improve his skills.

Above I have given two type of statements, no one going to influence other and Scrum master can ask team member to take a task. You know scrum is completely practice and adapt. Everything in scrum is an experiment. Scrum master will influence team members for making sprint success. But with his influence he makes the team in better shape. Like making every one has better skills. Because of these characteristics Scrum Master Job is not so simple in this process.

Because of above internal complexities velocity of the team not always depends on the number of team members.

Work burn down chart

A burn down chart contains, x-axis contains number of working days, and y-axis contains number of hours the team committed. In the scrum practice team member has to update how much work left for a task. They have to fill every day. The reason for asking how much time left is the estimate that we provided may not be the same with time that we had spend. So in the scrum practice we have to mention required time.


The above one is the sample burn down chart. Blue line is for actual burn down using total story points and days. It tells the average team effort that required. Red line is actual team progress.

Every day we have to count how many hours of work left and with respect to x-axis you have to point the remaining time left count value in the chart and you have to draw a straight line from previous time left point. In the above example you can see the work flow. Sometimes team did more than actual and sometimes they did less than average, so there are some ups and downs with respect to actual burn down line. This chart gives basic information about that team progress.

For a successful sprint the red line will end similar to blue line at the end of the sprint. And also this burn down chart tells the team how much work left from this sprint. Good thing in this Scrum is we know how many tasks left from this sprint. So based on the tasks list and user stories those pending tasks will be added to product back log and will be addressed in next sprints depends on priority.

How it works?

Scrum works based on time box. Time will be defined at the beginning of the scrum. Once the time box fixed then it won’t get changed. There won’t be any change in completion date, it cannot be extended. Then how can we resolve the issues or pending tasks? Tasks that are pending or issues will be added to product back log. In the scrum retrospect meeting teams will be discussed on these failures and team laggings and how to overcome. When next sprint planning begins, based on the complexity or issues and missing functionality from previous sprint may add to next sprint or post-pone to future sprints, but these items never skipped.

But there are some provisions for sprint team to do in these scenarios. If the team is comfortable to take pending items at their own interest without disturbing existing planned work. But it’s not a good practice all the time. Because of these types of practices it might create some problems to other teams who are not able to take additional work.

Requirements Changes

Change in requirement is a common activity in any development cycle. When requirements changes after sprint started then its product owner decision to call-off the sprint or wait till it ends. If change in requirement completely affecting existing sprint then sprint will be called-off and new sprint will begin with new plan. But the existing sprint neither works with new specification nor extended time line to accommodate changes. As a product owner he/she has to understand requirement changes and compare changes with existing specifications. If there are any small changes or new additional functionalities then current sprint will continue on their work and in the next sprint specification changes will be addressed as per the priority.

If change in specification result in change in entire logic or major change in logic then there are chances of stopping existing sprint and beginning new sprint. In this process Product owner takes help of scrum master and other people for understanding changes.

Common Questions

  1. Can Scrum work for non-software fields? Yes, scrum work for any field. It works for any person. Even it works for a student to complete his curriculum subjects. Scrum talks about step by step progress.
  2. When design comes to picture in Scrum? There is no specific phase for design. We can have a high level design at the beginning but lower level design can be done as the sprint progress. In each phase team has to spend some portion of their time for design if it required.
  3. Who will do documentation? Scrum never talks about documentation. It never opposes documentation. It suggests s that doesn’t spend much time of documentation. If company really looking documentation then add one more person to sprint team for documentation.
  4. What is the size of Sprint team? A team can be any size, there is no specific numbers. But for getting better results team size must not exceed 10. Why because scrum work on internal team members communication and healthy work environment. As team size increases there are more chances of getting issues. But every team must have some senior members along with junior members. If all are seniors then there won’t be any problem but if all of them are juniors then it’s a complex task for Scrum master to handle.
  5. Who will assign work to team members? No one will assign work to other person. Depends on team member’s understanding he can work on any task. But Scrum Master can suggest team member to take a particular task.

These are some of the questions. If you have any question you can rise. There is no restriction for asking or raising a question. I feel if people come-up with more questions then I will get more chances to learn and do experiments.

Scrum is not the best process to resolve all problems in the current system, but it gives solutions for most of the problems. There might be flaws or problem in the scrum, but again scrum always looks for challenges and it will adapt changes without changing its basic principles.

All the best to everyone who are willing to start scrum process.

September 6, 2010 Posted by | ABC of Scrum, Agile, Uncategorized | , , | 2 Comments