Should we kill Story Points?

I would like to start with a small conversation:

Manisha: Nilanjan, do you like pizza?

Nilanjan: Manisha, you should not eat Pizza because you have very high cholesterol and you have high blood pressure as well.

Manisha: Nilanjan I extremely sorry but I asked, do you like Pizza. I know I can't have pizza. I just want to know your opinion about Pizza.

Nilanjan: OH! No, I don't like Pizza.

Manisha: Thanks for the help.

I am having, Nilanjan syndrome with most of the people, I asked,  "Should we kill Story Points?". i.e.

Manisha: Mike, what do you think about killing story points?

Mike: OH! I share an entirely different view point with story point. We are not ready because we don't know how to write story and don't know how to break stories. 

Manisha: I am aware of our situation and very well educated about the preparation needed, before killing the story points. I just want to know if you prefer having story points or not. 

This problem is everywhere. I asked more than 7 people the same question and everyone of them start with an hour long lecture. I hate to admit but people were missing the entire point. I believe, I did enough of my ranting. Lets get to actual point. 

In my mind "Story Points" are the intended to help us in estimation but we failed because of below reasons:

• We started getting in "busy-ness accounting" mode - Where our focus is burn downs and velocity vs. Value of stories.
• We start comparing teams by Story Points. It is like comparing apples to oranges. Because of that teams started dropping good technical practices like TTD or refactoring to meet their estimates.
• We started holding people accountable for their story points and forces them to spend more and more time to come up with accurate story points. This end up with lots of waste.
• I  am not going into #noestimation aisle at all.  As "Tom Demarco" said in 1982, "The most optimistic prediction has a non-zero probability of coming True". But we are still trying to make it work, is a proof that we can't do it without aligning all the stars in one line. 

I would say, Story Points are not the root issue but people are. Managers/Coaches/Scrum Masters are misusing them and giving them wrong purpose. But a team needs lot of practice and course correction to become better at using Story Points. Our ultimate goal is to enable team to be able to break user stories into equal sizes to be to focus on throughput more easily.  

We can do that by Story Points or start by teaching them, how to break the stories in equal sizes without one using Story Points?.  In my mind, with both approaches, we would like to reach the same point. I would prefer the second one vs. first.

So, coming back to my initial question, should we kill Story Points :D? I would say, Yes! No Story Points would be the ultimate reach for any high performing and continuously improving agile teams. I am confident there will never be one right way to be agile about estimation and planning. Do whatever make sense for your team. But remember, agile is a vehicle we use to reach the destination. Our destination is our product and the value, which we deliver to our customers. Anything that takes our focus out of value should be challenged and questioned.

Next blog I will share how to transform teams from Story Points to No Story Points.

Spasiba!

Manisha

"The requested board cannot be viewed" - Jira problem

I started getting below error message, when I modified the boards filtering criteria. 

"The requested board cannot be viewed because it either does not exist or you do not have permission to view it."

The existing criteria was owned by previous coach, hence after modification, Jira was only showing me "Save As" button to same my filtering criteria. I promptly saved and verified few stories and checked all my swim-lanes. Everything was looking perfect, until one of my team member complained, that board is not accessible to him anymore. 

I knew, my changes were the culprit. I quickly reverted back my change and started investigating. After few minutes, I realized that the filter criteria, which I saved is only visible to me.  Since it was only visible to me, I could use the board but nobody else had access to it. 

I changed the permission to make it available for all my team members and BOOM!!! The problem vanished.  

Hope it helps

Manisha

Value of Standup

I am continuing my WHY series and here I go for standup.

Outcome of Standup:

We as a team should come out of standup, "knowing how to better attack our day". 

Standard 3 questions:

• What did you do yesterday or from the time we met?

• What will you do today?

• Are there any impediments in your way?

Why behind each question:
1) What did you do yesterday or from the time we met? (10-20% of time) 

• By sharing, what we finished yesterday, we get a sense of accomplishment and also helps in keeping us committed to our yesterday's promise.

• It is an opportunity to share any quick learning with the team

• It is also a good segue to the next questions.

2) What will you do today? (50-60 % of time)

• It helps us in planning our team day and allowing us to effectively plan and execute 

• It helps, team member/s raise a concern, if their plan, intersects or conflicts with your plan.

• It allows team member/s to share their knowledge or offer help to you, if they have better knowledge around the area.

• It allows team member/s to share their bad experience around the area.

3) Are there any impediments in your way? (20-30% of time)

• We raise them to be able to resolve it as a team as quickly as possible.

Benefits of a stand-up:

• It is short. 

• This saves everybody's time, as most of the issues raised will likely only require two people to be involved.

• It is effective in giving all team members an overview of where, for example, a project is.

Who should be part of it: 

I like the below story, since it best describes the situation.

Chicken: "Let's start a restaurant."

Pig: "Good idea, but what should we call it?"
Chicken: "How about 'Ham and Eggs'"
Pig: "No thanks. I'd be committed, you'd only be involved."

All the Pigs should be part of it and Chickens should be refrained from distracting team. 

Other things, we can discuss after standup:

Any thing, which impacts entire team can be quickly discussed after standup. Since the team is already together, one should take advantage of their focus switch. We may discuss topics which required entire teams attention. For example:

• Grooming a quick story

• quick project update

• quick environment update 

• Can be anything which impacts team

• reminding people about upcoming holidays 

Things not to share:

Any information, which does not help the team in planning the day better should not be shared. For example:

1. I was in feedback meeting with Mariam.
2. I was part of interview yesterday
3. I was looking into JIRA-xxxx 
4. Today I will be attending 1n1 with Mr. Blah Blah

References:

http://martinfowler.com/articles/itsNotJustStandingUp.html

https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

https://www.mountaingoatsoftware.com/blog/should-the-daily-standup-be-person-by-person-or-story-by-story

 http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm

https://www.scrumalliance.org/community/articles/2014/july/7-mistakes-during-the-daily-stand-up-meeting

Execution of Retrospective in Kanban world

No No, don’t worry I am not going to bore you with the benefit of retrospective. Retrospective is great tool if done RIGHT. My last blog touches on done right point little bit and will do a deep dive into done right topic soon.

But right now, I am wondering about a perfect way to do retrospective for teams following Kanban. Yes! you read it right! PERFECT WAY. So thought of sharing my experience on the execution aspect of retrospective for teams following Kanban.

My teams in past have been engaged in retrospective ceremony in following way : 

1. Regular 1 or 2 weeks cadence like the one scrum prescribes: Teams meet regularly and do their inspections in a regular rhythm. 
1. Advantages: Team is taking time to think and focus on continuous improvement at regular intervals. 
2. Disadvantage: Team members need to remember or recollect things on retrospective day.
2. Retrospective Item (RI) Limit based Cadence: Teams will have chart on the wall in team room or in confluence or google doc to collect retrospective items. Specifying the RI LIMIT for the team.  Something similar to WIP Limit. Team would meet as soon the limit is met. We should always keep 2-3 weeks upper bound limit. i.e. if they can't reach their RI Limit in 3 weeks they should huddle around to discuss points for improvement.
1. Advantages: Team controls the limit and does it, what feels right for them. My earlier team had done it and they kept the RI Limit to 3. The person writing 3rd item was responsible for scheduling a meeting on teams calendar. Agile Coach was responsible to remind them incase 2 or 3 weeks limit was broken.
2. Disadvantage: Team members might miss the retrospective since there is no fix cadence. Team with very low maturity level might feel overwhelmed..
3. Just in time Retrospective: Do it when you need it. Team members would call a meeting when they will feel the need of it. 

1. Advantages: Team members have full autonomy to call for a meeting, whenever they feel the need of it. The topics are fresh in they mind and they can find better solution by discussing them. It comparatively takes less time but requires high disciplined team.
2. Disadvantage: Same as earlier one, team members might miss the retrospective since there is no fix cadence. I would not suggest this style for any new team. This is definitely a good tool for mature and fully performing teams.

These are the three styles of retrospective cadence my teams have followed in past. Do share if you have tried something else and have worked well for your teams. I am trying to find a best way for distributed teams and my hunt is still on.

So long

Manisha

.  

Why we need Agile Retrospective?

Retrospective was designed to address Twelfth Agile Principle, which states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." 
 

Prime directive

“Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.” 

Purpose of Retrospective

Using Retrospective :

• we focus on learning and understanding instead of blaming 
• we should find the root cause of the problem vs. just finding the symptom 
• we Inspect in past and do the changes in FUTURE to get adapt according to our environment.
• we are improving our future work.
• we are extending the usefulness of current and future activities.
• team understands what went wrong together so they can change their way towards betterment.

What Agile Retrospective is not

• History Lesson learnt 
• Hot air (Blame Game)
• transform into complaint sessions: (People do not complain with bad intentions. They simply exteriorise what is affecting them. They have needs that are not being fulfilled and they need to express their emotions. Problems occur when the receiver is put off by the complaint and immediately enters defensive mode and counterattacks. )
• Change the world 
• Wishful thinking
• Ideas fest
• After action review 
• Postmortem  
• Project Review

Structure of a Retrospective 

• Set the stage ( What you can expect to get out of this exercise and choose right style for facilitation.)
• Gather data ( What )
• Generate insights ( So What )
• Decide what to do ( Now What)
• Close the retrospective ( Action Items)

Thanks

Manisha