Fixing the ToDo issue in Burndown chart

One of the most common mistakes a normalizing scrum team would do is – to neglect reducing the Todo.

It is important that the team would reduce Todo as they make progress in a sprint. This enables scrum master and product owner (and hence stake holders) to understand if the sprint is making progress or not.

We can monitor progress – status, using a burn down chart. Burndown should grow downwards (in a 45 degree slide) along with ideal line when team makes the estimated progress. It will start grow in a straight line, parallel to X coordinate (Time) when team misses to make progress. Sometimes, some delivering / progressing team also get flat line burndown as they miss to reduce ‘ToDo’.

So, it is an important task to a Scrum master (as an owner of monitoring role) to give feedback to team on this. But how to identify the tasks (or stories) where ToDo is not entered? Here is how:

Get the backlog (Of course, sprint backlog), and check for the following.

• Identify all the stories that are done, but still having ToDo remaining.
• Identify all the stories whose tasks are completed but the ToDo is not reset to zero.
• Most importantly, find all the stories where the ToDo and the estimated hours are same but the Done hours are entered.

Give this list of Taks, stories to your team asking to check if they can reset or reduce the ToDo, which will immediately reflect in better Burndown and hence will be projected as a delivering team.

Tracer bullet and more..

A tracer bullet is not a prototype. Why?
Because,
•A prototype is not deployed in production
•A prototype is not 'working software'.

A tracer bullet is not a POC. Why?
Because
•A POC may not be implementing a feature end to end.
•A POC is not a skeleton of an Epic.
•A POC may not be implementing any functionality

A tracer bullet is not a Sashimi. Why?
Because,
A Tracer bullet is a spike (time boxed) but a sashimi is a collection of (one or few) user stories that implement a thin version of a functionality.

Tracer Bullet is a Spike but a Spike may not be a tracer bullet. Why?
Because:
A spike may not deliver deploy-able value in all the cases. For example, a spike on environment compatibility study may not deliver any ship-able increment. But the knowledge acquired on this process would be the outcome of spike.

Y axis of Burndown chart

I have been interviewing scrum masters. After talking to 25+ candidates, this question still waits to get answered correctly.

What is the difference between release Burndown and sprint Burndown.

I ask this question differently, primarily to identify if the candidate is googling live.

I usually ask - what do you see in the y axis of Release Burndown and what do see in the y axis of Sprint Burndown chart?

Answers for those who are learning now: In Y axis, Sprint burn down has hours todo. Release burndown has story points todo. Should there be a burndown for CXOs, it would have SWAG (todo) of the features in Y axis.

It is always 'Time' ( days, releases or Qts) in X axis.

Mischievous cat of an elderly Guru or Cargo cult science

It is the story of a ‘Gurukul’ (school) that followed traditions religiously. 

This elderly Guru found his pet cat annoying - interfering their daily prayers. So he ordered the pupil’s leader to put that cat on leash, during prayer hours. Guru passed away on a breezy evening. They found his cat, dead under his bed. 

Then the pupil’s leader became Guru. On his first prayer, he looked around and ordered his students to go find a cat, as he needed a cat be tied in the third pillar of long corridor that goes to garden; to start his daily prayer.

The moral is, traditions are meaningless when they don’t deliver value.

Some teams don’t talk anything outside those three subjects during scrum.

“What did I do yesterday?”
“What will I do today?”
And “the impediments!”

When I noticed something missing on a scrum and checked the team member if he discussed the release plan for next week; the reply was ‘I will do it on Friday’. What if the deployment POC would be OOO on Friday?

So, there is no need to limit within three heads. Encourage your teams to talk everything to meet the delivery timeline. ‘Three heads’ is just a starting point for collaboration and we should talk as much as possible to deliver the deploy-able increment; ensure that won’t we end up making it a status report.

Agile provides developers..

Freedom to estimate: You estimate and you deliver. No need to work on someone else’s estimate.

Freedom to explain: One of the toughest tasks of a developer is to explain the delay to managers. Many a times, developer wouldn’t have any evidence to show that she/he has tried different options and the task still remains to be a research item. Agile provides means (VersionOne, JIRA) to track what was being done. After spending all the estimated hours, you will still be able to add ‘ToDo’ if really required.

Freedom to schedule: Generally, developers will be taking tasks one after another working closely with Leads till the project would be completed. But, agile lets developers to plan upfront. Developers will be able to plan their personal time accordingly. If a developer likes to take two weeks of vacation, he can own stories appropriately and deliver such that the others work wouldn’t be impacted.

Freedom to Speak: Developer has an opportunity to speak up every day (in case of scrum). If a developer thinks that the sprint zero was not done well then she/he can start a discussion on day one, instead of storing the work on his desktop and losing them in a crash after weeks. 

Benefits of listening: Conventionally, the collaboration was a role being played by leads. Agile multiples the chances for successful collaboration as everyone has the freedom / opportunity interact. Developers directly interact with another who has done a task similar to what he would try to start, and achieve it in very less time by collaboration. Earlier leads had to check with other modules and bind people together.

Work on a project- Not a module: When a developer start hearing what others do in a project every day, she/he gets a holistic view and minimizes the integration defects. His knowledge on different modules helps to grow a healthy cross functional group (which actually is a ‘Team’) instead of developers working in silos.

In general, Agile enables people to work as a team, and makes the issues very visible so that teams can work towards a solution. Agile is not a solution for practical issues teams may have; but it helps to identify issues, really visible.

NB : I use scrum and my views above are associated with that

The 6th Principle.

"Face-to-face conversation is the best form of communication (co-location)" 
– That is the sixthof 12 principles upon which the agile manifesto was proclaimed. 

We, the Agilists of Eastern Iowa Agile, a meet up group, gather regularly in Cedar Rapids. During the last meeting at Kirkwood College, we had Richard Lawrence of ‘Agile for all’ (http://www.agileforall.com/ ) delivering for us.
It was an interesting workshop with no presentations. The entire gathering took part in opining and realizing the values of agile principle. As an interesting exercise, we were asked to pick most favorite 3 from 12 Agile principles. And we were discussing the pros and cons. But later at the end, we noticed for everyone’s surprise, no one had picked the 7th principle. Then Rick concluded that this should be actually obsolete today and the communication media should have replaced the need to meet face to face. A ground breaking manifesto of 2001 becomes obsolete in 2014.

But, I think a Taskboard full of activities should certainly make a difference in the mid set of teams to bring a healthy competition and would help the team members to understand their contribution in overall delivery, no matter they meet face to face or not. My team is well distributed across the US geography and we ensure that Task board is shared by all of us in scrum, every day. 

Because the HR theories of T-groups are still there in books and are found fruitful. So, the truth should be standing tall somewhere between Yes and No. May be…

Velocity – Significance of averaging.

As I was splitting the remaining/partially done stories to the next sprint I wondered what would happen to the story points. Because the task estimates are getting split and carried forward whereas the story point remains the same for both the sprints. 

Further, if a sprint is going to accumulate a few heavy stories from previous sprints and get credited in the current sprint then what would happen to the velocity? So, 

•It is important to consider the average velocity when you take a shot on SWAG.
•Story points completed in a sprint may not reflect the effectiveness of a sprint.