ShriKant Vashishtha

Your Team Got AI Tools. Why Isn’t Anything Moving?

I was recently working with a software team that had just been handed Cursor licenses — one for every developer on the team. Their leadership was excited. The CTO had made the call personally. AI-assisted development was going to change everything.

Sprint 1 ended. Not a single story was done.

Not in review. Not in testing. Not deployed. Done.

I want to tell you this had nothing to do with Cursor. The team did not know how to use it well yet – that was true – but that was not the reason.

Scrum Mythbusters : Sprint Backlog is Fixed During the Sprint!

by ShriKant Vashishtha Leave a Comment

A sprint in Scrum begins with a Sprint planning event in which Scrum team considers the Product Backlog Items (PBIs) from the top of the Product Backlog for the upcoming sprint.

The main activities of Sprint planning event are to:

select the PBIs the team forecasts it can deliver during the sprint
come to a consensus on a Sprint Goal
plan how to achieve the Sprint Goal

What is a Sprint Goal?

A Scrum team jointly commits to a short statement of the value it intends to deliver during the sprint. This is guided by the Product Owner. This becomes the focus of all work in the sprint and the team creates a Product Increment to meet the Sprint Goal.

Sprint Goal can be formed in many different ways.

Introducing Mocktail: A Java Framework to Cache/Mock the External Dependency Response for Automated Tests

by ShriKant Vashishtha Leave a Comment

Most of the software applications use interfacing points, e.g. a database, XML datasource, or a restful service. Such interfacing points pose challenges while creating repeatable automated tests. The challenges are as follows:

Tests Become Flaky

Tests become flaky as they depend on the connection itself. If a database or a restful service is down, the tests dependent on them fail.

Tests that sometimes work and sometimes do not, break the trust of a team. Sometimes just because of that people stop paying attention to the test suite and may not fix them. After some time such tests become unmaintainable and people stop using them. As a result, the entire investment in creating such tests goes in a drain.

When Story Point Estimation Doesn’t Work!

by ShriKant Vashishtha Leave a Comment

Story points are used to arrive at a shared understanding around a PBI. This works well when a team works collaboratively. Such teams take a PBI and swarm together to complete it. For instance, a front-end developer does her job, along with a designer and a back-end developer. In other similar scenarios, a team can have a mix of specialists and full-stack developers. These folks pair up and keep switching from one story to another as part of pair switching.

In all these scenarios, having a shared understanding on a PBI helps. That’s the reason why planning poker and in turn story points work.

Agile Estimation: Should We Use T-Shirt Sizing Instead of Story Points?

by ShriKant Vashishtha 1 Comment

As we have seen in the earlier chapter, it doesn’t make sense to map story points with time just because they are not the same thing. It’s like comparing apples with oranges.

Some teams may be okay with these problems and still may want to get ahead with mapping a story point with time. However some teams may want to fix that.

In my experience, the teams which are already mapping a story point with time, it becomes difficult to unlearn the mapping even if the team wants to.

Recently, in one such new team, instead of story points, we began with the idea of T-shirt size based relative estimation.