Product Backlog

Product backlog can be described as evolving requirements books. The requirements here are in prioritized manner.

The product backlog contains ideas and business requirements given by the people who are interested in the product, people who are going to work on that.

These are just a small piece of information which carries a lot for the project. The product backlog can be created by doing a brain storming session with the people who are interested in the product and people who knows similar product. There is no need for the Product owner or the team to get the entire product backlog ready to kick off the first sprint. It is enough if the product backlog has contents that are ready for the first sprint. While the team is working on first sprint, the product owner can fill in stuffs in the product backlog.

The Product back log can contain stuffs like user requirements, any kind of impediments that needs to be removed or whatever is important for the product to be developed. The product backlog is dynamic requirements documentation. This document keeps changing. New stuffs get added, stuffs get deleted, and priority gets changed and so on.

As said earlier the items in the product backlog are prioritized based on the business needs and values. The product owner has the full right to change the priority of the stuffs in the product backlog. Though there may many people who are interested in the product, it will be the one person (Product owners) responsibility to prioritize stuffs in the product backlog. If someone wants to change the priority in the product backlog, he has to discuss with the product and the PO can make the change if needed.

To estimate the stuff in the product backlog, the PO sits with the team members and expertise. All these people will make an estimate on the stuffs in the product backlog. Estimation should not be done based on hours. Estimation should be made with respect to points. These estimations are subjected to changes as the team pulls the stuff from the product backlog for the sprint.

Posted in Agile | Tagged | 2 Comments

Scrum Master Jobs

There are some basic responsibilities that a scrum master should do 

  1. Implementing Scrum Process
  2. To Implement a Scrum process he should teach about the process to the Scrum Team and to the organization.
  3. Discuss with the team to make a prioritized product backlog.
  4. Discuss with the product owner to create the Product backlog.
  5. Responsible for conducting scrum meetings (Daily Scrum, Sprint Planning, Sprint Retrospective)
  6. Shield the team from any outside attacks.
  7. Shield the team from any management impediments.
  8. Should solve the impediments.
  9. Motivates to team to be more open.
  10. He should be good listener and a problem solver.


Posted in Agile | Tagged | Leave a comment

Scrum Team: Decision Making

Decision making is one of the highest priority job in scrum team. Most of the decision has to be taken by the team itself. To solve a problem, most of the time the team itself has to rely on itself to make a quick and clean decision. Decisions like reading books, looking into forums help, webpage to solve the problem are simple solution that the team can make itself.

Some time it becomes necessary for the team to rely on a third party or a consultant to solve a problem. Such kind of decision can be taken by scrum master. Sometimes such training may need the management permission and it has to be sorted out before arranging.

Once the team gets accustomed to scrum methodology, the team has to learn to take decision on its own rather than depending on outsiders to take a decision.

If the scrum master is not able to make a decision during the daily scrum, it is better to sit with the team/team member and arrive at a decision.

Apart from decision making after daily scrum, there are also places where the scrum team has to make decision. This comes with the points that arise in the retrospective meeting. To solve such issues, some kind of initiative and a tracking method can be followed. A simple excel sheet to describe the problem, the solution arrived and the person who is going to take care of the impediment can be put into a excel sheet.




Person In charge


In consistency in scripts

used for automation

Code is labeled daily by the end of the day for automation



Effort spent are not updated

All should update their effort in rally

before daily scrum


Similar kind of stuff in excel sheet will help the team to keep track of the impediments and the person who is taking care of it.

Posted in Agile | Tagged | Leave a comment

Scrum Master: Identifying and Removing Impediments

It is the whole responsibility of the Scrum Master to LISTEN and REMOVE the impediments. The scrum master should try to remove the impediments as early as possible. A growing impediments list indicates a two things , One is the Scrum master is not removing the impediments and the other One is that the management is not showing any responsibility to remove the impediments.    

Since Scrum master’s primary job is to remove the impediments, he should pay more time in understanding the nature of the impediment that the team/team player is facing. The reason being rather than providing a temporary fix to the impediment, it is always better to find the root cause of the problem and cut it out there. While doing it please don’t call the team member or team for a meeting to find the root cause.    

Removing impediments is just like making Highways. Once the bumps (Impediments) are removed the team can just go in their natural velocity and complete the targets on time.    

Also when a scrum master smells a rat or something is going wrong with couple of team members, try to solve the problem and don’t try to pin point the problem causer. It is always better to understand the problem from both the ends and jump to a conclusion than pinpointing to the mistakes.    

If the scrum master fails to remove the impediments on time then at some time the team members will lose faith on the scrum master and they will stop telling the impediments in the daily scrum.

If the scrum master is not able to remove an impediment within a day, then he should update about his plans to remove the impediment. It’s better to tell the truth than hiding it.


Posted in Agile | Tagged | Leave a comment

Daily Scrum Meeting

Daily Scrum Meeting or Daily Stand up Meeting


This is a kind of meeting that the scrum team attends daily. During the meeting only one Pig is allowed to talk and all other pigs and chickens will be listening. The person will update about his status or the progress that he has made in his current task or story.

Who should start first?

Hahaha..Nice question… I guess. But still we will start with the person who arrived last for the standup meeting.

Where should the meeting take place?

I prefer the meeting to take place @ the same place @ the same time daily. The reason for not shuffling the place is I guess shuffling the place daily will again a problem. This meeting place and time will become something live Pavlov reaction. As soon as the clock struck 10.00 all pigs and chickens will assemble at the rendezvous.

What should be discussed?

 There are three questions that a team member should answer.

  1. What did you do yesterday?

    Here the team member is expected to tell that is relevant to the project that he is doing the stand up. Any irrelevant update should be stopped immediately by the scrum master

  2. What will you work on today?

    The team member should tell the team about his plan for the day in the project what the team is working.

  3. Do you have any problem in doing the work today?

    Each team member has a well planned work to do for the day as well as for the sprint. If the team member feels that something is hindering him/her to do the day’s work, that can be brought to light during the stand up meeting. If the team member is being slowed down by some impediments then it’s going to affect the whole team as well.     

    The Scrum master should pitch in and try to solve the problem the team/team member is facing. Some problems can be solved immediately. If there are some problems that are related to company’s process or top level management then it has to be taken seriously. Though it is not possible to arrive at a concrete solution, the scrum master and the management should try to provide a temporary fix to keep the teams velocity moving.    

    During the standup the team member should keep their answers to the 3 questions very brief. No huge explanations about the work are needed at the meeting time. Any such explanation can be give to the needed person off the meeting. Also any detailed explanation needed can be discussed outside the meeting time.    

    Any sort of impediment like the server not working, internet problem can be brought to notice during the daily stand up meeting.    

    Remember all meetings in Scrum are Time Boxed and this meeting is time boxed only for 15 Minutes.



Posted in Agile | Tagged | Leave a comment

User Stories

User stories are just small snippets of the customer, user requirement. It is just a small piece of information that’s enough to provide a huge amount of work.

  • This small piece of information is enough for a company to build up lots of new features in their product.
  • These user stories can be any piece of write up or it can be an idea that came into your mind
  • Writing down user stories on a Piece of paper will be more precise and clear than writing lots of information on a word document.

    Since requirements keep changing, it is better to small user stories than writing a big requirements specification and changing a lots of thing when a Change request comes.

Posted in Agile | Tagged | Leave a comment

First step towards Scrum Master …

Hmmm .. Atlast I made the first step towards becoming a Certified Scrum Master…Great . The CSM training was held in Bangalore on Oct 23 and 24 , 2010 .  There were around 20 people for the training .  The experience in scrum was scattered in the group. Some have extensively worked on Scrum and Some yet to begin .. Four scrum teams were formed . There were lots of exercise and games to teach the real scrum. Though it was called us game, the main outcome of the game was to teach us the difficulties that one will face as a scrum master in the real work.

Posted in Agile | Tagged | Leave a comment