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!

☆

☆

☆

☆

☆

Comparative Agility

Adopting Agile / Scrum in your team and organization can be a challenging task. However, with the help of servant leaders with good understanding of Agile principles and practices, your team can adopt a process that works well for you. Once you've established a process however, things can get monotonous. One of the tools I recommend using to help you break the monotony, and try to move forward with something new is Comparative Agility.

Comparative Agility is a survey with questions about your Agile practices. The survey takes about a half an hour or so, and I found the results to be really useful. I recommend one of the following two approaches - take the survey on your own and share the results in a retrospective; or possibly, take the survey collectively as a team in a retrospective, and talk about the results. 

When I took the survey, I was interested in knowing how my team was doing in our effort to adopt Scrum. I also wanted to know where I could help focus my team's attention in our efforts for continuous improvement.

The results definitely brought some of our shortcomings into focus. I could then engage the team in a conversation about why we should concentrate on areas where the survey says we are lacking; and think about what roadblocks we have along that path. I could also use the data to inform our leadership team to help us on our path to adopting Agile.

I found the survey questions and results really useful. I'd definitely recommend taking the time to do this activity.

Here are some results from my team:

Dimension Analysis:

Characteristics Analysis:

Rate this post!

☆

☆

☆

☆

☆

Triage

Along with the 4 recommended Scrum meetings, I usually include a Triage meeting in my implementation of the Scrum process. I thought I'd share some pointers on triage.

What is triage?

Triage is a quick meeting to go over new / incoming defects. In the meeting, we sort defects and set priorities on them. Triage is a good place to groom the minimum viable product backlog, so all the tasks - stories and defects are prioritized in a single list. 

Participants, Frequency, Duration:

I recommend having the Product Owner and the Scrum Master participate in the triage meeting. The team can be made optional attendees. Specific team members join the call if they have opened / are working on defects that need to be explained in detail. 

Frequency of triage meetings is dependent on defect inflow. I have found that I'm comfortable with triage of about 8-10 issues in a single session.

As with any meeting in Agile, it is important to time-box the triage activity. Triage is not a place to solve the issues, or fight about the defect's exact place in the backlog. Triage is a meeting for building quick consensus and clarity on what the issue is, and what release it really needs to be fixed in.

Scrub of defects before the meeting:

In order for the triage meeting to be productive, I spend some time looking at defects before the meeting. I look for several things in this time:

1. Duplicates - if an issue is a duplicate of something that is already in the backlog, clean it up.
2. Change project - if an issue is incorrectly opened against our project, or if I can quickly tell that it should really be assigned to another team, clean that up as well.
3. Comments - I take a little time to look at code to figure out some technical details about the defect. I write my quick analysis as a comment on the defect. This is intended to give a head-start to the developer who is eventually going to fix it. I also try to add some notes that will help set priority during the meeting.

Priority setting:

Priority calls are owned by Product Owners. However, most product owners I have worked with usually take suggestions from everyone involved. I recommend following the MoSCoW principle for priority:

1. Must have - these are defects that "gate" a release. They must be fixed in order for the minimum viable product to ship.
2. Should have - these are "high" priority defects, which should really be fixed for the minimum viable product release.
3. Could have - these are "medium" or "low" priority defects, which can be included in the release if there is time, or if they are really low hanging fruits.
4. Won't have - these are defects that the product owner decides not to fix. The reason for this is up to the product owner. For example - defects that are deemed corner cases, or defects that are needless nitpicking.

As a Scrum Master, triage meetings help give me some idea about what is in front of the team - defects and stories included. This helps me look at forest from the trees. Doing a scrub of defects for triage also keeps me in the loop on latest code changes that the team is making. This helps me be a better code-reviewer. I have found triage meetings to be immensely helpful.

Rate this post!

☆

☆

☆

☆

☆

Spikes

I think Spikes are a very interesting topic to talk about. I have seen a lot of teams struggling with the concept, and potentially abusing the term. I want to write about Spikes, in order to try to clarify their meaning and give some examples of how spikes can be useful and how they may potentially be abused.

What is a spike?

A spike is a time-boxed technical investigation / research undertaken by a single developer or the team in order to solve a specific problem. Spikes usually don't produce working output.

Spikes usually produce example code that is used to build the working output.

Etymology:

On The Agile Dictionary, there is a comment (3rd from the top when I'm writing this) :

Paul says:

My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. When climbing, we might stop to drive a spike into the rock face. Driving the spike is not actual climbing — it does not move us closer to the top — but rather it enables future climbing.

I don't know how true this is, but I definitely like the analogy here.

Example use of a spike:

I recently built an app, which helps users prepare for DMV test. The app is pulls some data from my data source on the web, parses it and shows it to the user. When I started working on the app, I didn't know how to talk to a web data source from an Android app. I was stuck and needed a technical investigation -- a spike. 

I used this spike to try to pull data from a test website. I didn't necessarily need the official app website for the spike, I could use any test data. My aim was to find an implementation that accepted a URL as input; and spit out the text from that URL. I decided to have a long time box, because my app update was intended for this activity. I couldn't proceed with any real development without this investigation.

When I was done with the spike, I didn't have a solution that I could simply copy-paste into the code for my app. Instead, I had an example which I could work off of.

Example abuse of a spike:

I can think about 2 specific examples where spikes are abused:

1. Spikes for accurate estimation: Spikes allow developers to familiarize themselves with the code. This can lead to more accurate estimation. If all your spikes are driven by a need to have accurate estimates, you need to question whether that is really needed. 

If your team runs into issues where they aren't comfortable putting a number on a user story without first going through and knowing the design, I'd like to point you to my article on Story Estimation. I have mentioned a few things there which might be useful to you.

2. Spikes for requirement clarification: I have seen teams using spikes for clarifying the requirement(s). In this semantic change of 'Spike', a developer needs to put on a Product Owner hat to figure out the details of the "what?" and not the "how?". If your team is engaging in spikes because stories aren't clear, I'd encourage holding your Product Owner responsible for providing a reasonably clear stories, and a decent minimum viable feature set for the release. 

In conclusion, I'd encourage teams to:
1. Stick to the definition of the spike I mention here.
2. Take on Spikes only when they are necessary, not before that. You don't want spend time on a spike for a story that never sees light of the day. 
3. Set a time-box for the spike.

At best, spikes are excellent tools for producing working solutions quickly. At worst, spikes can convert your Agile process into Waterfall.

Rate this post!

☆

☆

☆

☆

☆