ShriKant Vashishtha

Story Point Mapping with Hours – Key Ingredient to Burnouts?

ShriKant Vashishtha · September 8, 2013 · Leave a Comment

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?

When BDD (Behaviour Driven Development) may not work?

ShriKant Vashishtha · September 2, 2013 · Leave a Comment

For quite some time there have been talks on using BDD in order to have:

Better collaboration between Business Analysts (BAs), developers and testers.
A common domain language for functional testing and for defining functional acceptance criteria, which everybody in the team understands.

Why BDD?

BDD offers following advantages:

Ability to write test cases (scenarios) and acceptance criteria before performing any development. This whole idea is termed as Acceptance Test Driven Development (ATDD).
Provides a common domain language, which everybody across the board (developer, tester, BA and business) understands. As at the end it’s plain English, it’s simplest to learn compared to other DSLs (domain specific languages).BDD example
Helps in eliminating waste by minimizing handshakes. If you take a look at the above-mentioned example, testers and BAs can write a test or acceptance scenario using a BDD template (highlighted in Yellow) with plane English

Developer/tester can then fill in the blanks, i.e. implement the test case using programming language or script.

Writing text doesn’t require any IDE like Visual Studio or Eclipse. The test/acceptance scenario can be written in a Notepad too and then pushed to Version Control System, which is then picked up by developers/testers to implement.

As BAs, developers and testers work only one single source of truth (BDD test), it minimizes the handshakes and reduces waste. Also it is well understood by everyone as test-scenario is in plain English.
[Read more…] about When BDD (Behaviour Driven Development) may not work?

Story Mapping and/vs Process Maps

ShriKant Vashishtha · February 12, 2013 · 10 Comments

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.

Agile Offshore: Why Distributed Demo / Showcase is so Important?

ShriKant Vashishtha · January 14, 2013 · 1 Comment

Demo is an integral and important part of Scrum ceremonies. Important because that’s the whole point of being Agile. You get early feedback from Product Owner and stakeholders and fine-tune the product if required. Also this is sometimes the only occasion for offshore team when sponsors and business actually get to see the real contribution of offshore team. There are valid reasons also when someone from onsite team gives the demo. They include:

Language problem. I worked with a French team in which stakeholders and business were more at ease to talk in French.
Completely opposite time-zones which may not allow a lot of collaboration.

The advantages of distributed demo far outweighs the ones of onsite demo.

Developer First Test Automation

ShriKant Vashishtha · January 7, 2013 · 3 Comments

Waterfall made a clear demarcation between developers and testers. While moving from waterfall to Agile, both development and testing has to be grinded in a way that you can’t separate from testing activity from development.

People in Agile projects are moving away from “developers vs testers” (we vs they) culture and are collaborating in order to deliver the product at the end of sprint. Sprint success is major goal instead of developer or tester success.

That has been a great change in the recent years and which also means some more miles to go before reaching the state of true collaboration. Even today, quality is considered to be the major responsibility of testers which in reality shouldn’t be the case.

As developer is primarily involved in developing the functionality, (s)he needs to have tremendous commitment in building quality into source code and if bugs come, primary responsibility should be of developers. It doesn’t mean that testers don’t have any responsibility. They need to move away from their traditional role of just finding bugs and instead should be able to focus on creating infrastructure, frameworks for building quality within and also focus on exploratory testing, improving product etc.

In Automation testing, though automation test creation is the responsibility of the testers, developers lay the foundation of creating those test cases.

Sometimes this demarcation doesn’t work in a smooth way. While developing the automation tests, tester discovers many basic foundational pieces missing, which eventually hampers the tester in developing those tests.

In one of the teams I worked with, team came out with a norm which helped the testers a lot.

Developers suggested to write the first functional test of the user-story themselves, which laid the foundation and provided all required resources to build further tests. While developing those tests, developers identified many issues which otherwise would have blocked testers. As developers eventually fix these issues, it made much more sense that they themselves discover those issues.

Based on this basic foundation, testers further elaborate the test cases and create more automation tests. The norm worked pretty well for the team and also helped developers understanding the issues testers face on daily basis.

It’s step ahead towards ATDD. However this team was not using BDD or tools required for ATDD and was not planning to move towards them in near future. Developer-first norm worked quite well for them.