Agile Buddha

Scrum Mythbusters : Sprint Backlog is Fixed During the Sprint!

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.

Story Points for Bugs or Defects

by ShriKant Vashishtha Leave a Comment

Generally, a sprint backlog contains bugs as well apart from user stories. In these situations, a common question is should we assign story points to the bugs.

If the team does not assign a story point value to this work, velocity will show the amount of *potential* business value the team is delivering in each sprint. This way, it becomes evident that team is going more slowly through the work than it could if legacy bugs were not there.

If the team assigns points to the bug-fixing effort, the team shows its true capacity to accomplish work. This way, it shows both *potential* business value delivered and effort gone in bug fixing part.