Agile

Who all should Participate in Story Point Sizing Activity?

There are folks who may be moving from waterfall to agile approach.

They in general divide the estimates in terms of development estimates and testing estimates. These estimates are separately done by the representatives of developers and testers. These representatives are either not part of the team or may not be doing that work.

In Agile teams, the story point sizing activity is done by the whole development team.

Just to reiterate again, all cross-functional team-members participate in the sizing activity. Also, there are no separate story points for development and testing activities which could potentially enable the team members to estimate them separately and combine them together to come up with the resultant size of a story.

What is a Story Point?

by ShriKant Vashishtha 1 Comment

Story point is a unit of measure of estimation for the overall size of the work that will be required to fully implement a user story.

Story point has no direct relation with time even though people may get tempted to map it with time in order to get an hourly estimate to complete a user story.

To understand story point concept better, it’ll help to take an analogy with distance.

Why to Use Relative Sizing?

by ShriKant Vashishtha Leave a Comment

If you draw a straight line on a white board and ask people how long the line is, different people will have different answers.

However if you ask the same folks around how long the line B is in comparison to line A, almost unanimously you’ll get the same reply, i.e. “double the size of line A”

The reason – we humans are visual people. We struggle quantifying something in absolute terms but it’s not that difficult to compare one quantity with another.

All About Story Points and Agile Estimation Series

by ShriKant Vashishtha 1 Comment

Lots of Scrum teams have been using story points and planning poker for relative sizing.

However, this is one of the concepts like pointers in C, which troubles most of the teams and they all have their own interpretations on the subject. Lots of material has been written. However it becomes difficult to join all the dots together for any team-member to digest at one place. This series of posts is an attempt to simplify learning and make the concept as clear as possible.

Some of the posts were written in the past and some I am writing now in order to have completeness around the subject. This list will keep getting updated as I write new posts on the subject.

The First Law of Distributed Agile

by ShriKant Vashishtha Leave a Comment

With the advent of communication revolution, people looking for nomad life and orgs looking for skilled knowledge works irrespective of geographical boundaries, distribution of teams has become a norm rather than exception.

However, distribution of teams has a lot more pitfalls than many people realize, especially when people do them just because they can or it’s convenient.

This article is about putting team distribution in a perspective and show why every possible distribution is no fun.

Once, I was working with a distributed team which had half of its team members working from Bangalore and the other half from CA, USA.

While speaking to the team members, I came to know that team members were struggling to work in distributed mode as they had to collaborate with their distributed partners in a completely opposite timezone (12 hours of time difference).

It had started affecting their personal lives as they used to take their meetings to their home as well.

Apart from conducting their distributed daily Scrum in the night, Bangalore team-members had to have a call in the morning too when CA based folks used to hand-over the work to their counter parts in India. Other sprint events as well used to happen in this time period.

Team tried different ideas coming from their retrospectives to make it work. But the situation didn’t improve.

During one such conversations, I asked if it’s possible to have two separate geographical teams working on independent features and collaborate on integration points. Essentially one team in CA focuses on one set of features and other team in Bangalore focuses on other set of features.

It turned out that it was certainly possible but the option was never thought through before.

The work could certainly be distributed without distributing the team geographically. That’s how we get to The First Law of Distributed Agile

Don’t Distribute Your Team in the First Place

Irrespective of the available tools and remote communication channels, face to face communication is much more powerful than its remote counterpart.

Remote communication by default brings a bunch of overheads along. Because of high transaction cost associated with remote communication, people start hoarding the inventory in form of working on only READY stories and in turn introducing waste.

Face-to-face interactions on the other hand speed up building the high-trust environment leading towards self-organized teams.

In a given context, it’s recommended to form a collocated team. Sometimes, it may not be possible to form a collocated team considering some constraints. But we should be keep going to the First Law and try to make it happen.

One such example was a case of a Scrum team in a large bank. Most of its developers were working from India but testers were working from Malaysia. In short term, it was not possible to form a collocated team considering the testing team-members working from Malaysia only had relevant domain knowledge.

However in the long term, the domain knowledge could be transferred to development team based in India. Eventually the leadership helped in resolving this problem and it became a completely collocated team.

Summary

First law of Distributed Agile – don’t distribute if you can avoid distributing in the first place.
If you really need to distribute, prefer forming local cross-functional teams and let the representatives from a number of individual Scrum teams collaborate through Scrum of Scrums.

Agile

Summary

References