Responsibilities of a Scrum Team

Scrum defines 3 roles - scrum master, product owner and the team. 

A product owner is charged with shaping the product, making decisions about future development that best serves the customers. 

A scrum master acts as a coach, guiding the team to follow good technical and Scrum practices, setting the team up for success.  

But what is the team responsible for? Here are some thoughts:

Meet sprint commitments - A Scrum team defines the scope of an iteration by committing to a limited set of the product backlog. It is important that the team exhibits reasonable predictability in meeting these commitments. This gives external parties the confidence that the team can deliver on what it says. This type of confidence usually entails high independence for the team.

Identify issues early, mitigate risk - A Scrum Master can facilitate this, but it is primarily up to the team to identify and communicate issues that can derail the sprint commitments. Knowing about issues early gives the team time - to swarm, or get help from external parties, or negotiate story scope. This applies not only to sprint commitments, but also to product itself. The team is best suited to identify issues as it builds the product. Communicating issues early on is a great first step to mitigating any risk.

Knowledge creation and sharing - The goal of each sprint is two-fold: build increments to the product, and create knowledge. Learning is an important part of sustaining agility. Knowledge creation and sharing can include things like understanding the business better, or advancing knowledge of the technology within the team.

Unit and Automation Tests - The team is responsible for prioritizing creation / maintenance of unit test suite and automation test suite. As the product grows in size, it takes more and more time for manual comprehensive testing. In order to sustain good pace of development, unit tests and automation tests are critical.

Respect each other - This includes things like being punctual, actively participating in daily Scrums, retrospectives and planning meetings. A healthy team is one, that can bring up and acknowledge problem areas. This cannot be done if team members don't respect each other.

Assist each other - Going down a path of "this is my story" and "that is your story" is setting yourself up for failure. The team, the scrum master and the product owner are all in it together. They need to take the time to assist each other to meet their sprint commitments. Assisting each other goes a long way in raising the overall skill level on the team.

Communication - Each team member is responsible for making sure they keep the right set of people in the loop on the tasks they are working on. At a minimum, each team member should keep the Scrum Master in the loop so that s/he can facilitate communication with other people.

Delivery of high quality product - Quality begins at the source. It is important for each person on the team to take ownership of quality for what they are building. With measures like code reviews, manual and automated tests, the team is responsible for delivering a high quality product. No matter how quick the turn-around from an idea to finished product, if quality is sub-par it is destined to fail.

Continuous Improvement - Last and certainly not the least, the team is responsible for asking the question - "how can we do this better?" This is key to greatness!

One of the most important tasks in doing Agile is to understand how to be a part of the team. Having some guidance on what that means can make the job a little bit easier.

Rate this post!

☆

☆

☆

☆

☆

How are story points and hours related?

There are more than 1 ways of estimating stories. Here is 1 way that I like:

Relative sizing:

Let's begin by taking an example story - As someone preparing to run a marathon, I would like to run 1.5 miles, so that I can build my stamina.

Now, lets say I have 3 'developers' on my team, with varying levels of stamina. Each person will take different amount of time to complete the story. But, if we were to call this level of effort as a "5", we take the amount of time each person takes to complete the work, out of the picture. 

Let's say this story is your reference for relative sizing. When the developers estimate a set of stories, they can estimate the level of effort a story will take by comparing with the reference. If the level of effort is more, they can pick the next number in Fibonacci series (8). If it is less, pick the earlier one (3). If the estimate level is much much more, pick 2 numbers ahead (13).

Value the aggregates:

A sum of story points that the team completes in a sprint, averaged over a few sprints is your velocity. This aggregate of story points is valuable to the team as one of the data points for sprint commitments.

If stories targeted to a release are estimated, the aggregate is valuable, because it allows for some predictions on when the body of work will be ready to ship. For example, if a set of stories is sized to 1000 story points, and your velocity is 100 story points per sprint, you can say that it may take 8-12 sprints to complete that body of work.

To conclude, I would discourage scrum masters from going down the route of assigning X days = Y story points. Instead, value relative sizing and aggregates of story points.

Rate this post!

☆

☆

☆

☆

☆

Work In Progress Limits

One of the problems I've seen in dealing with new Scrum teams is work items finishing on the very last minute of the very last day of the sprint. I refer to this phenomenon as 'falling off the cliff burndown'. Here is one example:

As you can see in the burndown report, most of the stories are finishing on the very last day of the sprint for this team.

There can be several reasons why this is happening. From what I have seen, 2 reasons stand out:

1.  The story size is too big, or 
2.  The team is starting stories but not finishing them

WIP Limits help you solve the second problem. Enforcing WIP limits forces your team to "start finishing". This is important, because we don't want to find out on the last day of the sprint that a few things can't be finished. Good Agile teams are predictable throughout the sprint, and raise the flag early on work items that won't finish by the end of the iteration.

If your team is struggling with work items finishing on the last day of the sprint, try applying WIP limits. Start off with a lower WIP limit number, say 2 or 3. Applying a WIP limit of 3 to your "in progress" column means that only 3 work items can stay in that column at a time. The team needs to swarm on those 3 items, and get them finished, before they are allowed to start new work. 

Raise or lower the WIP limit as needed, based on conversations in retrospectives. Ask your team members to respect the WIP limit. A good real life examples of WIP limits is - Cars on highways tend to be able to go at the speed limit if the number of cars is less. Jam packed highways don't usually have cars going at high speeds. 

One of my new favorite adage about WIP limits is that they help you stop starting, and start finishing.

Rate this post!

☆

☆

☆

☆

☆

Negotiations and User Stories

Well written user stories follow the INVEST acronym. User stories should be – Independent, Negotiable, Valuable, Estimate-able, Small and Testable.

Let’s talk about 'negotiable' quality of user stories.

The goal of organizing the work in the form of user stories and sprints is to build small increments of the product and get feedback. The Scrum Master is responsible for keeping scope creep and distractions in check.

As the team builds stories, there can be instances where the Product Owner may need to make some changes to the acceptance criteria. Is this scope creep?

The Product Owner has the responsibility of clarifying the user story as the team builds it. It is important to realize that although the Product Owner should have a good idea about what the end product looks like, she may not necessarily know all the ins and outs. As the team builds a small increment, the Product Owner has the right to request changes she sees fit. In such situations the team can –

• Decide that the change is something they can accept in the current sprint, or
• Add a story in the backlog and make the change in a later sprint

There is no formula that can tell you what option to take. This is a judgment call.

To illustrate this point, let me give you an example. Let’s say I’m almost done with my grocery shopping when my wife calls and asks me to get some extra milk. In this situation, I can either –

• get the milk (and the brownie points) or
• decide that waiting another 30mins at the checkout line is not worth it.

Negotiating user stories can be a source of frustration. The development team may not like making changes on the fly, but it is important to know that user stories are about collaborating to build what is needed, and not necessarily build just what is written. 

Rate this post!

☆

☆

☆

☆

☆