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.

Priorities

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.

ABC of Scrum – Continue

Scrum Challenges

I know after reading previous content you might feel that, this approach is so simple and easy to follow. But scrum itself a challenge. The team is committing to management that we are going to do these stories in this scrum. Team has to work hard to reach that goal. In the scrum every member has equal responsibility, everyone has to work and mingle with each other. Creating a comfort atmosphere among team member is a challenging task. The entire sprint depends on each individual and team communication. In this scrum approach there won’t be any boss. So when there is no boss, we have to educate each team member such that they have to feel responsible. I know it’s hard to follow for existing team who are working when boss put some pressure on them and commanding them. If any one feels that I am going to work when someone commands and look at me, and then just get of the scrum, it is not for you.

Until unless people realizes with what is exactly scrum it never going to be succeed. The success of the scrum practice completely depends on how the company manages to educate the member to understand this process. You know basic motto of scrum practice is “Adapt”. I can give guarantee that 99% scrum will be failed at initial stage, not because of lack of knowledge or understanding but lack of proper sprint planning. The team which will learn from mistakes can sustain quickly than other team.

Most of the people have misunderstanding that with this approach there won’t be any product manager. Technically it is true but product manager can manage the scrum, as a scrum master. But it real scrum practice it is not advisable. It needs lot of changes in product manger attitude towards the team.

Product Back Log

What is a product back log? Who is going to maintain this? How many back logs do we need to maintain for a project? I think these are questions might rise in your brain. Let’s clear these questions first

Product back log is a place to keep all our requirements. Anyone can update product back log. Requirements will be collected for clients, end user and product expertise and will be posted in product back log. This product back log holds all the requirements relate to a project. There will be only on back log exists for one project. There should not be more than one. We must have a common place to trace all requirements. If we have more than one then it is very complicated to maintain requirements and priorities and updates. We might miss some updates at one place it will lead so many complications and it is also create more confusion to people who are going to use or refer the back log for updates or requirements. So there should be only one product back log exists for one project.

Product owner is responsible for the product back log. Client can be act as product owner. The product owner responsibility is to update priorities and understand the requirements.

Product owner

Product owner is the person who is going to manage product back log. Product owner has to review product back log periodically and updates priorities. Priorities will be updated based on client needs and ROI (Return on Investment). Product owner will give priorities but he is not involved in work load or efforts. How much a team can do, will completely depends on the team. They have to decide how much they can do, and they have to provide estimates for the task that are going to work on.

Product owner has right to terminate current sprint and can start new sprint based on product back log. If team has any impediments then product owner has to resolve those impediments. He is responsible for solving any product related issues. Team need to discuss and have to resolve any problem exist in the team, if they are not able to resolve then they can discuss with product owner. Creating such environment in the team for resolving their problems is scrum master responsibility.

Scrum Master

Scrum master is the person who is looking at sprint team and monitors the progress. The scrum master can be a member of the sprint team. But a scrum master look at one sprint team. He is going to monitor one team progress. He is completely responsible for entire team. He has so many responsible in the Scrum practice. He is the person who will do actual work in sprint planning.

Responsibilities:

• He has to protect team from other interference.
• He has to respond to each and every problem of the team members
• He is responsible for team interactions
• He is responsible for sprint planning
  • He has to collect each team member opinion and effort regarding each task.
  • He has to give points to each user story after having discussion with team.
  • He has to make sure that no one influences other team member for giving efforts.
  • He has to make sure that all team members understood the requirements clearly.
  • He is responsible for not making any changes in the committed work after sprint started.

Scrum master is never being responsible for sprint release. He is responsible for work progress. The team is going to be responsible for entire sprint release.