Agile Buddha
Demystifying Agile, Getting to its Core
I ask teams to do commitment driven planning during early stages of scrum adoption. For you to commit to a sprint goal, you need to know current team capacity. Team capacity is calculated as per people availability in that sprint.
Let’s take an example.
[Read more…] about How To Do Effective Capacity Planning on The Scrum Team
This is based on a true story of a project I was involved in and that was also the first ever Agile projects I worked on. As I came from straight from waterfall background and didn’t have enough Agile experience, it made a lot of sense to us to map a story point with number of hours for obvious reasons. We mapped story point with ideal hours. Initially things went well. However after a few months, we started getting into difficult waters because of following problems:
We began to witness clashes among developers over estimations. As story point was mapped with number of hours, it directly mapped with the skill of a developer. For instance, a senior developer could finish a user-story in 2 hours. Another not-so-skilled developer or new-in-the-team developer could finish the same user-story in say 8 hours. That started causing planning meetings with clashes, disagreements and also spurts of indirect bullying from senior guys. As a result, not so experienced developers started spelling similar smaller estimates even though it caused them to work longer hours. As it was a distributed augmented team, we also started witnessing lack of trust within team because of those reasons.
Also customer didn’t see any significant change in team velocity even though productivity improved multi-fold. “YOU ARE NOT PRODUCTIVE GUYS…”
[Read more…] about Story Point Mapping with Hours – Key Ingredient to Burnouts?
Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an activity to be done by people who are going to work on it. Hence a simpler sizing technique was needed so that everyone(developers, testers) can understand and use it easily.
Story points is a very powerful sizing technique. It has various advantages as I mentioned in my earlier articles.
Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds.
[Read more…] about Story Points and Man Hours – When To Use Them and Why?
One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the organisation.
However, haven’t you observed that many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.
In-fact I find story points as a good distraction to the team. Let me go over why having this “additional layer of indirection” provided by story points can be very useful.
[Read more…] about Agile Estimation: 9 Reasons Why You Should Use Story Points