What is Sprint Planning?

Why Sprint Planning:

Remember is Scrum we work in baby steps. Sprint Planning is the event where we plan what we can achieve as a Scrum Team in Two weeks. We need all members of the team in the Sprint Planning. Giving a sports analogy this is the meeting on the day of the big game in the locker room.

Agenda:

1. OPENING   – Welcome, Parking Lot, Working Agreement, Action Items  for meeting
2. WHAT CAN WE DO IN THIS SPRINT –  This is a discussion between the PO and the team to decide how many Product Backlog items can be completed in this sprint.
3. THINK ABOUT PLANNED vs UNPLANNED WORK
4. DECIDE A SPRINT GOAL- Collectively the team and PO write a sprint goal defining the purpose of the sprint.
5. TASK BREAKDOWN- The team members work in groups to break down tasks for each Product Backlog Item. (This can take a while)
6. SPRINT FORECASTING AND CONFIDENCE VOTE. Scrum Master checks with the team if they feel comfortable with the work they have planned.
7. CLOSE – Clear Parking Lot. Assign names to Action Items and do a Retrospective on how the meeting went.

10 Smells of an InEffective Sprint Plan

1. The team pulls stories that do not have acceptance criteria
2. The meeting finishes really quickly
3. The meeting goes forever 6 to 8 hours
4. Everyone has laptops open and no one is talking to each other
5. Team members are being told what to do
6. Stories and Acceptance Criteria are being written for the first time here
7. The team is estimating the story here for the first time
8. The Scrum Master is controlling the entire meeting
9. New Team members feel lost
10. Managers are sitting idle watching the plan instead of participating in it

Note: In Distributed teams sometimes the sprint planning is done over two days. Esp when you have PO in one country like the USA and the team in completely opposite time zone like Singapore.

 

Agile Defined

The manifesto is governed by 4 Values and 12 Principles. Being Agile sticks when companies focus ground up starting with building the value system followed by practicing the values, doing some of the practices and hence getting the benefits. This is often referred as Inside Out Agility.

Under the Agile Umbrella, there are many methods. Scrum is a method, Kanban is another. There are many others as well. Within each of these methods, there are many practices.   

In general Being Agile means, you are using one or more of the Agile frameworks but are surely following the four values and 12 principles as much as you can.

The recommended approach to go with imbibing Agility is something called Inside Out Agility. This focuses on making sustainable changes based on Culture, Structure, Agile Values and Principles and then following practices like Agile and Scrum. Most of the Agile transformation programs that follow an outside in Agility in order to gain the benefit of Agility. While the Inside out is not an easy path it has proven to be more successful than any other approach.

How Does Scrum Feel?

Let’s get some keywords out of the way first.  

Scrum  – A framework to deliver value to the customer iteratively.

Sprint – A time box where an increment of value is delivered. Mostly 1, 2, 3 or 4 weeks.

Roles-  Scrum has Three Roles.

• 1. Scrum Master – Remover of impediments. Team motivator, Servant leader
  2. Product Owner – Voice of the customer. Works with team and stakeholder to create value.
  3. Development Team – A self-organized cross-functional team that delivers value.
  4. Scrum Team – Collectively the Scrum Master, Product Owner, and Development team are called this.

Events– The Scrum Framework has four productive events. ( meetings )

• 1. Sprint Planning – Plan the work of sprint so that we can deliver value at the end of Sprint.
  2. Daily Scrum – A 15-minute daily plan.
  3. Sprint Review –  A product feedback, inspect and adapt cycle.
  4. Sprint Retrospective – A process improvement Inspect, Adapt Cycle

Artifacts – Things of value produced in a time-box.

1. Product Backlog – A backlog is a term for a list of things to do, also called Requirements. This is owned by the Product Owner
2. Sprint Backlog –  Also called As Task Board or Scrum Board.A tool used by the development team to be transparent about the work they are doing in the sprint.
3. Product Increment – This is the reason we do Scrum. To build something of value in Short iterations of time.

An easy way to remember the core Scrum Framework is with the 3-4-3 rule. Yes, there are only 10 things to the Scrum Framework.

In Scrum, 3 Roles, the Scrum Master, Product Owner, and Development team go to 4 Events – Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective in which the produce 3 core Artifacts. The Product Backlog, Sprint Backlog and the Product Increment Itself.

Let us look at what goes on in one sprint for a Scrum Team which is doing two-week sprints.

Day 1: Sprint Plan -The Development Team, Product Owner, and Scrum Master meet in a sprint planning event. This is normally 4 hours max for a two-week sprint. In this event, the team “Pulls” items that are ordered as high priority and breaks them into what done means for each item.  The team defines a Sprint Goal that they can march towards.

As the team finishes the sprint planning the Scrum Master is cleaning up the task board and getting it ready for the current sprint. The team members help prepare the board too.

Day 2:

The team starts with a Daily Scrum in the morning. The Daily Scrum is done in front of the task board.

It is a good practice to update the task board before the daily scrum to keep the daily scrum going smooth.

Day 5:

This team works on something called one-piece workflow. Which means they really like to finish one story completely before pulling another.

The task board on Day 5 looks like this. ( This is just an example)

The team has finished story A and is working on B on Day 5.

What else do you notice that is different from the task board today?

The team has also updated the burndown chart. Their burndown chart has the number of tasks on the Y-Axis and the number of days on X-Axis.

They also demo the  Backlog item A to the Product owner and get acceptance from him.

Day 9:

 

The team has finished two stories and decides not to pull the third story as planned as they have no more time. They get acceptance on the second story too. Way to go team.  You Rock!.

They meet in the evening for half an hour to “Get Ready for the Sprint Review”.

Day 10:

The team is delighted to have finished two of three stories. This is called the Say Do Ratio.

Sprint Review:  The Development Team, Product Owner, Scrum Master meet for an hour and a half to talk about what was delivered in the sprint. 

The product owner talks about the two stories completed and then the team members take turn to show the two stories to the stakeholders in the room. 

They get feedback back about a small change that was requested in the Story B. The product owner says he will get it changed.

The sprint review ends with a small celebration.

Sprint Retrospective:

The Development team, Product Owner, and Scrum Master meet to discuss improvements they can do to the process so that they can do better. They plan to meet for an hour and a half.

The entire Scrum team talks about the two impediments that came in between the sprint, that slowed them down due to which the second story took a bit longer than they thought. One of them being story B turned out to be much bigger than they thought.

They take an action item to break stories smaller so that this problem does not happen again. The Scrum Master erases all content in the room except the one action item that they took. 

This sprint ends.

New ScrumMaster Checklist

This list is a place for new ScrumMasters for their very first ScrumMaster Job.

Welcome to your new ScrumMaster task. It is a tough one and sure is confusing. No Organization actually has a role like this. So where do you start.

Set up a meeting with  your manager and the manager of the team that you will be ScrumMaster of.

This meeting is important so you can expect what kinds of things they are expecting you to do. You should talk to them about things you are expecting to do

1. Make impediments Visible.
2. Facilitate the 4 core Scrum Meetings
3. Remove Impediments

That is it. Make sure they are okay with these three things. If you hear no for all three of them, don’t take this job.There are many other things you can do but the above three are core to your job.

Make impediments Visible.

Next create a impediment board and make sure the managers know that you will put something here and if you cannot figure out how to solve it in a day or two, you will ask for their help. Also if possible make this a physical board.

Facilitate 4 Core Meetings.

Find out when the sprints are starting. If the team is not yet sprinting, just add the work they are each doing into one list and call that the product backlog for now.

Find our who the product owner. You have to make sure you have a Product Owner for Scrum to work.

In general all Scrum Meetings should follow the following principles

1) They need to be high energy

2) They need to start in time

3) Only the Team and PO are needed. Don’t invite anyone yet

4) They always end before time

A general agenda for all meeting

1. Opening
2. Purpose of the event
3. Task-board for each event
4.  Close with Action Items
5.  Do a mini retro about the event itself.

Here is the  five items for each of the meetings.

{Work in Progress}

Request your contribution to Scrum Awareness In India

State of Scrum In India

Hello my name is Vibhu Srinivasan and some of you may know me. I am passionate about Agile practices and practice agile in everything I do from running  business to helping at home.  I am presenting on a topic called “Is Scrum For India” in the upcoming Scrum Gathering India to be held in Pune on the 26th and 27th of July 2013

In order to faciliate the session, I am trying to gather some data to really understand if scrum is working for teams in India. I feel you could help.

To do this, I  would need
1) To meet 25 scrum teams from Service and product companies alike.
2) To carry out a Survey from 200 independent practitioners in India on Scrum.

I would appreciate your response, if you are able to contribute some time of your team.

Based on your preference, I can visit your team for around 30 minutes in Hyderabad, Pune, Bangalore or Gurgaon to conduct the study. We could also do this through Skype or some other video channel.
The responses by the teams will be used only for our internal studies and the broadcast of the results will not carry your teams’ reference unless  we have your categorical permission for the same. If you so wish,  your teams’ video will be shown at the conference; if you don’t then we will not mention anything. As always I respect your organization’s privacy and will refrain from saying anything about you, your product or the customer if you choose to not expose that information

Please send an email to me with your preference for either a meeting with the team or  for the team to participate in a survey. My personal email is vibhu.srinivasan@gmail.com

Please note this is purely for benefit of the agile community and there is no commercial intent here.
There are no gifts or bribes associated with this. I am hoping you will do this because you care about the agile practices in the Indian context.

What is Velocity?

Velocity can be termed as the run rate of the team . Agile teams use this metric to measure how much work was done in a sprint so that we know how much more is left to actually make the reason.

Let take a simple example.

The team has ten stories whose total story point is 140. They pulled around 30 points of work this sprint. They finished 25 points. This 25 is their run rate.

With this the team and product owner can project how many more sprints are needed to finish the work.

We are assuming that the team is using story points here.

Some myths about velocity
1. Teams velocity keeps increasing over time.
2. A team having a better run rate is a better team
3. Since some team last year delivered at a certain velocity, this new team will also deliver at the same velocity
4 Velocity can be a predictable measure sprint after sprint even if we keep moving team members in and out.
I have seen many team members mindlessly argue over the effectiveness of velocity and end up wasting valuable time.

In fact in the beginning in 2005, as a developer, I would not see the point of such calculations. After a while, I got used to this and stopped worrying about such metrics and just focused on writing clean code.

Also, velocity as a measure only works well with teams that tend to practice Scrum and not as much with Kanban or XP teams.

Many scrum masters get into this coach mode with a single focus to help increase the velocity of the team. Instead, I would encourage ScrumMasters to look at completing the work they pulled min style, as well as help team and team members, identify waste in the system.

This metric is not as important as a number of automated unit test or number of production bug in the system.

Is Scrum Agile dead in India?

To put things in perspective I am a Certifed Scrum Trainer and have been working with teams in India for three years.i am a developer that has been in this business for 18 years mostly in XP teams.

I was recently in a very interesting discussion with one of the handful of folks in India that I know of who actually understands the essence behind Agile. What we got talking was a very simple topic
Does a model like Scrum or Kanban which is widely popular elsewhere really applicable to Indian software industry.

Millions of developers code away daily in Indian organisations. More than sixty percent of Indian software industry is still service industry. By which I mean “Cheap outsourced fast software”

Put in a simpler way ” clean the mess and work on software western developers do not want to work on”. I have visited almost every large or medium service organisation in India in last three years. I am yet to see a highly motivated self directed high performance team.

I recently got into a very uncomfortable situation as a agile consultant, when the customer asked me – I want a American quality agile coach for whom I can spend 300k but for a Indian quality coach I can only pay 60 k. This is really top guy in a very big product company. Basically I was told that coaches in India suck .well most of them do ,but not every one of them.

Some of the most common fears that Indian management have to deal with

• large fixed bid projects

Even to win a fixed bid project Indian companies have to guarantee that they will deliver all the features within a certain range.there are huge penalties for missing the cost deadline

• thousands of new hires on a daily basis enter the system

a recent training coordinator explained to me how they filter through the low quality hires in the first six months of training
Most of the new hires have to go to a military style training program to unlearn whatever little they learnt in their engineering program’s. I saw the training Kanban board which has a day by day measure of where the new grads are in their learning curriculum. Nowhere in this new curriculum was the agile mindset.

• after doing scrum we are stressed out

most of the customers from counties like US and UK are misusing the term commitment . Or this could be a misinterpretation of Indian managers
The teams are expected to commit whatever they finish in a sprint.

• To manage a manager there is a manager

due to the sheer scale and volume of Indian organisations you get promoted to a manager from a developer even before you finish compiling the first program you ever wrote. There is a person to watch every person . For all these years the managers have been herding sheep. Where do they all go if you become agile.

• affinity to westerers

it is sad but it is true. Indians take “athithi devo bava” way too seriously. Between a average Indian guy who naturally lies, does jugaad for everything and the white male who visits India more often to take pictures of poverty . Even if the Indian guy is speaking sense the people , crowd around the white guy who has no clue what problems Indian organisations speak . While it is a meritocratic society, if you look at the speakers for agile2013.in ,Indias largest agile conference where there are only a handful speakers from India.this goes to prove that this agile thing is not really working here. When I go around Indian organisations , I am often challenged by managers that they disagree on something because Craig said so or Pete said so. I hardly see Indian managers disagree with anything visitors have to say. I never hear them say Venkat said this or Mahesh said this.

• we are like this only

Here are some things only happening in India – sticky notes in India do not stick in the wall,Indian software teams have to deal with a group called facilities . Many a times we would put up a Kanban board in the evening only to come back in the morning that the ruthless facilities people have cleaned up the entire board. Most Indian organisations have to deal with late night calls, so they end up coming very late, then they go to many unwanted manager meetings , then have lunch ,then tea and samosas ,then get ready to do athithi devo Bhavan after 6 pm. Where is the time to code in between all this.

Things from Scrum and agile that does not work well in India

1 Daily standup – it is very tough to do this hanging in a bus as U commute,or when stuck in traffic or as I stuff Some curry in a hurry as the customer only comes online after 9 pm

2. The concept of cross functional team – not possible in really large firms . The PDI index or power distance index for India is more that 70 percent. Hierarchy in a team in expected behaviour.so unless I am told what to do, I do not do anything .

3 servant leadership – the term servant has a very different meaning in the Indian culture.hence when I say in the CSM class,people tend to look at this concept strangely.

4 scrum master – this is a county of project managers .there is a manager for everything. It is probably the largest revenue generator for PMI. Where do all these PM,s go now.

5 CMMI baggage – most of the companies are at CMM level 5 and also have lots of internal audits and procedures .case in point in one agile product company in India, you have to leave your cell phone at the gate and are not generally needed to adhere to the strict code of conduct.

6. The nature of distributed agile makes life a huge stress factor on family life often called as offshore widows .

7 . product owners not here. This is huge issue as the PO is never in India and they have to stretch a lot on their side to actually work with a team

8. Managers are not authorised to push back or say no to odd ball customer requests .because hourly rate counts, they will do anything to keep a body billing. One of the early projects I did many many years ago was a code review projects, we got paid 1 dollar a line of code. So I was needed to at Least review 300 lines a day. Better still this was code I could not even compile.

As a disclaimer there are a handful of small to medium agile organisations that do an awesome job in India

.Also all names here are fictional and do not represent anyone that is real

I really think Indian companies should not blindly follow processes not made in India. They could take whatever has been the norm for years and then come up with something that Works in India

I highly encourage a debate that I would love to facilitate with whoever is interested to debate really find something that works for the business scenarios that are very unique to this region.

What is a Product Backlog?

Product Backlog is one the artifacts of Scrum. The product owner writes the product backlog. It is an ordered list.

This is a list like grocery list. Each item in the product backlog is called a product backlog item (PBI) . The product owner orders into one order based on business value , risk  and technical input

It is just an excel list. Typical columns in a product backlog are

1. Item Number
2. Story Description
3. Size ( also called as estimate by team)
4. Order – This is one number. 1, 2, 3, 4 and so on
5. Business Value – The PO is accountable to get the correct business value working with customer, stakeholders and rest of the organization.
6. Definition of ready – Is this item sprint ready – yes or no
7. Team name – the team that is working on an item
8. Sprint number
9. Release number
10. Acceptance Criteria. – More details on the requirement

Here is an example image on mountain goat sofware

What is Scrum?

Scrum in 10 lines

1. Scrum is a framework to manage complex projects based on empirical process control mechanisms.
2. Scrum is based on inspection, adaption, timebox and transparency.
3. Scrum is based on five values – openness, respect, courage, commitment and focus
4. Scrum teams do work in timeboxes called Sprint which is either 1, 2, 3, or 4 weeks.
5. There are three roles Product Owner, Team and ScrumMaster
6. ScrumMaster is a leadership role who facilitates scrum ceremonies, keeps the team together, coaches team on Scrum and agile and makes impediments visible.
7. Product Owner is the customer representative or customer who specifies what needs to be done in a an order and accepts work when done.
8. Team has 5- 9 people that does the work for the product owner and shows an increment of work each iteration.
9. Scrum Ceremonies are Sprint Planning, Daily Scrum, Sprint Review and Retrospective.
10. Scrum can apply to any kind of work that can be planned for at least a week.

Agile Conference presentations – a call to raise the bar

Here is an open call from me to people presenting at conferences in India. While it is heartening to see more people show up at the Agile events, nothing substantially new is being brought to notice. The maturity level is so low and very few presentations make sense to the audience. These topics would not have any importance when presented outside india.

The bygone year saw many kinds of agile conferences coming up. Scrum Bangalore, Scrum India, Agile Hyderabad, Agile India, Agile Tour in various cities. Having had quite a bit of depth in this field for many years now. I feel, here are some duties of organizers and presenters. I think this applies to any other technical conference too, esp. the ones that involve people taking out their personal time to come to these conferences.

Remember there are a few hundred thousand of us software developers, testers, architects, PM’s etc. in this country. Many are just waking to hearing these terms for the first time. What you say impacts those that hear you.

Organizers

If you are organizing any sort of conference, please ask for the deck and a small write up before the conference.

Put a serious deadline to the presenters submitting this for review.

Get a small group of trust worthy and unbiased reviewers to select the presenters.

Get reviewers to commit. Many seem to simply want to be in the review committee to be popular.

Make the review process transparent, based on the true spirit of Agile .

Every presenter deserves a constructive feedback.

If you need me to review for free, I will be happy to commit to this, provided you guarantee wine and cheese in return

If you have a theme, then make sure presentations have a flow in the conference. Example – If the theme is Agile Engineering, then do not do the first one on Unit testing and then the next one on scrum for service companies.

Publish feedback of presenters openly.

Keynotes takes away the charm from the real stuff.

Misleading information by a presenter, will have serious repercussions on your conference image.

Organizers; please put a guideline on acceptance of topic .Ex.how many slides and how dense the slide deck should be.

Presenters

Do your home work. Remember, the rules of presentation have changed these days. Not just less dense deck, but you should have very few slides.

NO DECKS PLEASE (lesser the better) Trainers around the world are going away from simply doing a deck based presentation to a more dynamic presentation technique. Audience must be actively involved.
Learning Rule #1 – The audience learn most from what they do in the class. So involve them however big a group.

make a mental/ small note of your ideas in a book.

One slide one word or one picture. – Do not do text at all. You can give a dense handouts along with your presentation.

Use back of the room techniques if needed. Please see Sharan Bowman’s 4C techniques. Connections, Concepts, Concrete Practice, Conclusions.

If you are a developer or architect, “SHOW CODE” What better way to teach what you know that show me the code. “Talk is cheap , Show me the code” ( Stolen text from someone in the family. Ask your audience to code).

If you are a tester – show how you test with tools. walk the talk. Ask audience to test.
“Start with the end in mind” – What is the final message you want to convey.?

Use simple anecdotes to convey your message.
“Story Telling” is a great way to get the point across.

When someone asks a question, repeat the question and open it up for discussion with audience, before answering.

Remember every question could be important. So don’t ignore any specific questions.