Things to consider before starting new work committed to an iteration

To do Scrum well, teams need to consist of "generalizing specialists". This means that the team has specialists, but they are willing to help each other out to meet sprint goals. If specialists keep working in their silos, the sprint can get into jeopardy. 

As the team burns through the sprint backlog, individual team members may find themselves with some free time. Consider for example, the case of a developer who has checked in all her code, and is waiting for the tester to finish the verification. Or, take the example of a tester who finishes writing the behavior tests for a feature before it is developed. This is a good time for people to look around, and see how they can help the team finish work items that are already in progress. If specialists start new work, they can cause damage at bottleneck points in the system.

Here are some guidelines that Scrum Masters can share with their teams, in order to keep work flowing through the system.

1. For the work item you are currently working on, check with your peers to see if they need any help with any tasks. For example - front-end developer can help with a back-end or a test task. If your peer needs help, help them. Don't go to #2,3,4 below. 

2. Check with your team if they need any help with stories already in progress. If the team needs help, do that. Don't go to #3,4 below. 

3. Take care of house-keeping items, like unit test coverage, automation coverage, framework maintenance etc. while you have a few hours as your work items go through the system and finish. Don't go to #4 below. 

4. Talk to your team about putting the next high priority work item in progress. If they agree, start working on it. 

It is important that each team member recognizes that they all succeed and fail together as a team. The sprint commitments are owned by the team and not by individual specialists / assignees of work items. Team members who are willing to work outside their comfort zones make a successful Agile / Scrum team.

Rate this post!

☆

☆

☆

☆

☆

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!

☆

☆

☆

☆

☆