Manage sprint dependencies with chained pull requests

Introduction

In many cases, it appears that there are dependent tickets in a sprint within a team or even across several scrum teams. In a perfect world those dependencies would be avoided, but unfortunately, in real-world the business needs prevail and to shorten the release cycle dependencies are introduced. This is a technical article that focuses on a way to manage dependent tasks in software development teams.

The old-fashioned way

The straight-forward approach would be to start working on a task as soon as the dependent task is merged into the mainstream branch. With such an approach though, some team members will idle or wait until a task is ready to be picked up. At some point, there will be little to no time to implement the remaining dependent tasks. Finally, the last tasks are doomed, carried over to the next sprint and the team is unhappy.

Why does this happen even though the capacity of the team is correctly estimated? Mostly because of the idle time when waiting for a team member to complete a task. There are often delays and even though they might be small in time have an exponential impact especially on short sprints.

Working on dependent tasks simultaneously

Yes, there is a way to do that with a small overhead. When team members work on tasks simultaneously, there are several advantages.

Better collaboration

When team members work simultaneously on dependent tasks, this is a kind of pair programming model. One team member needs to be aware of its dependency and another team member needs to be aware of its dependant. The team has now wider knowledge of the problems being solved during the current sprint.

Avoiding the idle time

When tasks are approached concurrently, there is no need to wait until something is fixed (or made available). All team members can work on the dependant tasks simultaneously with higher than usual ad-hoc discussions due to the questions that arise from time to time.

Pull requests ready for code review earlier

When a team member is using a branch from which his/her branch originates from, it is always easier to approve the origin pull request. This is mostly because of the awareness of the implementation of the dependent ticket. The origin is well tested and reviewed already during the implementation process. The pull request of origin is a no longer unknown territory.

Using chained (stacked) pull requests

To accomplish this level of concurrency within the team, the proper tooling is needed. With GIT-based versioning systems, this is straight-forward to implement. The following steps define the process in more detail.

Dependency tree (working on 6 dependent tasks simultaneously)

Outline the dependencies clearly

During the planning session for the current sprint, the dependency chain between the tasks has to be defined. The chain of pull requests will follow exactly this same definition. Changing the chain in the mid-development process is not desired due to the huge rebasing overhead.

Start with the root tasks first

In every dependency chain, there are always tasks that are not dependent on any other task. Those are the root tasks of the chain. Work on those tasks can immediately be started from day one.

Do core implementation first

This might contradict with the test-driven development where tests are implemented first. To reduce the complexity of managing the dependency chain of pull requests though, it is easier to work on core implementation first. This way the team members that are dependent on a particular functionality will have access to it sooner.

Organize and code review in a FIFO queue

The first branch created must be code-reviewed first and merged into the mainstream first. After each merge, the continuous integration will trigger and if there are issues like breaking the mainstream build they will be fixed on time while the problem is still small.

The overhead

Although there are many benefits in maintaining a chain of dependent branches in the versioning system, there are also some small deficiencies.

Rebasing or merging

The chain of pull requests need to be kept in sync and this costs effort. The modern tools though provide easy one-click synchronization with the origin branch when there are no conflicts. This can be used for on-demand synchronization when it is safe to pull in the changes from the origin. When the build is green and the functionality is usable, it is time to sync.

Teamwork

Maintaining the dependency chain requires a collaborative team and each team member should be ready and eager to collaborate with the other team members. Working on a chain cannot be productive when people are isolated and don’t talk with each other.

Conclusion

It is always preferable to push back dependent tickets out of the current sprint. When for business needs though, such tasks need to be implemented simultaneously, maintaining a chain of derived branches is a very convenient and successful approach to handle the dependency overhead between different tasks.

The tooling

Scrumpy Planning Poker is a great tool for estimating stories correctly. The stories estimated properly will help the team clearly define its capacity and have a successful sprint. When tickets are estimated, dependent tickets are revealed through discussion and marked as such in the ticketing system. You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The following video shows how to use the Scrumpy Planning Poker application by becoming a moderator and creating a refinement session. Scrumpy Planning Poker saves you time and keeps your team engaged!

May 26, 2018June 5, 2018

Confluence, Jira, Stride and Slack integrations

Introduction

Scrumpy Planning Poker integrates with various external systems like Jira and Confluence to make the voting process as transparent and convenient as possible. In this post, we shall discuss, the most common integrations that are a must-have for every scrum team using story points for estimating tasks.

Setting up the integrations

When you sign in as a room moderator to the Scrumpy Planning Poker application, you can configure the integrations from the settings page:

Inside the settings, there are several integrations mainly done through user/API token combinations or web-hook URLs.

Jira integration

The Jira integration is described in detail in Jira integration for Scrumpy Planning Poker and consists of entering the details:

Jira root URL. This is the root domain which you open when navigating to the Jira ticketing system. For example, your-company.atlassian.net.
Jira user. This is the user on whose behalf Scrumpy Planning Poker will update story points, add comments with estimate summary or create Confluence summary pages for the refinement sessions. For example, your.name@your-company.com.
Jira API token. This is the API token that can be obtained from the Atlassian Account Manager. The API token is used to authorize your Jira user to make comments, update story points or create Confluence pages.

After the Jira integration is set up, when a ticket is refined its story points are automatically updated and in addition to that, a comment is added when and how it was estimated.

Confluence integration

The integration with Confluence uses the same link and credentials as the Jira integration. You can specify which Confluence space will be used as a container for the summary pages created from the refinements.

When the last participant leaves a planning poker room, and this room is set up for summarizing in Confluence, a new Confluence page is created. The page is a summary of the voting session containing anonymous votes from the participants in the refinement session. The following screenshot shows an example:

Stride integration

The Stride application integration is used to publish messages in a chat room when a story is refined. A brief message similar to the one added as a comment in the refined Jira ticket is printed, for example:

The integration consists of entering the following details in the settings dialog box:

Stride room URL for posting messages. This is the link that can be copied from Stride when a bot needs to publish messages there. An example is “https://api.atlassian.com/site/aedcbe61-1d38-4c3c-8781-aff9d49e7e12/conversation/5abe1d2c-d447-41ea-9cae-6ff44b1ecbf0/message”
Stride authorization token. This token can be obtained from the Stride application. For example: e6fK73KSUiRiKysQaQdb.

Slack integration

The Slack application integration is used to publish messages in a chat room when a story is refined. A brief message similar to the one added as a comment in the refined Jira ticket is printed, for example:

The integration consists of entering the following details in the settings dialog box:

Slack web-hook URL. This link can be taken from the Slack settings for the Incoming web-hook integration page. The appearance of the posting robot can be customized there also. The link can be entered in the settings dialog box of Scrumpy Planning Poker.

Integration demo

The following video shows how the Jira integration is used and the advantages when Scrumpy Planning Poker is directly integrated with Jira:

May 4, 2018February 10, 2021

Comparison metrics for agile teams

Introduction

It is quite a challenge to compare agile teams and find out really why teams should be compared at first place. How can the agile process benefit from comparing teams working on different tasks from different domains?

Creating a competition

Definitely, teams shouldn’t be compared directly and challenged one against another just because of different metrics. This can only create a demotivation. Instead, metrics should be only used to create an equal opportunity for each team to compete with the rest. This way, performance is increased indirectly, by the will of teams, not from an outside urge.

The metrics for creating equal opportunities

Below is a list of basic metrics that can be used to measure differences between teams. Those metrics show nothing more but the ability to compete with the rest of the teams on equal grounds. Equal metrics mean equal opportunity.

Successful sprints

If the sprint is just a time frame, it wouldn’t make sense to have sprints at all. It is a milestone and should have a goal. The sprint goal (the most essential set of stories in the sprint) is the bigger milestone and the successful sprint (all stories completed) is the smaller one. You can bring life to sprints by scheduling cross-team sprint demo at the end of the sprint where teams present their achievements. This way teams will compete with each other to show a successful sprint and the achievements accomplished. You can’t motivate without showing the goal to reach.

Can this be a game of over- and under- commitment? When the team under-commits, it would be obvious to the others during the sprint demo – there will be fewer achievements. If the team over-commits, the presenter will show a yet another failed sprint. The feeling that the team did something successfully according to the plan unlocks a motivation to deliver more. Teams are satisfied by the work done.

Velocity stability and the honest estimation

It is a knowledge work indeed and not a factory assembly work, but when there is no knowledge in the whole team to understand a problem and estimate its solution, this means that the problem was not researched in advance.

A time-boxed spike in the previous sprint to create a research paper on the subject plus a document review from the whole team will make it easy to split the implementation into smaller stories and properly estimate them. For complex tasks, a bigger technical design document is needed with a list of implementation stories.

The spike and the creation of the technical design document are again a set of stories that can be properly estimated. It is all about defining well the structure and sequence of tasks to implement a more complex solution. You can avoid placing a story for which there is not enough knowledge in the team, but instead make a task to research and gain this knowledge. Then estimation is easy and accurate.

Capacity predictability (avoiding unexpected work)

Research can be done first, implementation will follow later. During the research problems pop-up, tickets are created and estimated. You can know well enough what will follow the next sprint. What is known can be estimated and planned. What is not known can have a time-boxed research ticket and again estimated and planned. It is all about properly splitting the bigger task into smaller chunks.

Complex tasks can be started in advance, even if just to find out a separate set of stories need to be created. But still, it helps to control the risk from the unknown.

Support work and firefighting unexpected production issues are usually done in time-boxed Kanban mode outside the sprint where time to first response and SLA breaches on critical issues are used for comparison metrics between teams.

Team availability (time spent on tasks divided by total time in a sprint)

This is what the team did while the team members were working on estimated tasks. If a team gets more distraction than other teams (technical courses, knowledge sharing, or other internal tasks outside the sprint), this means that it is time to take actions to make availability equal between the teams. This is the time that is spent on estimated tasks and the only way to keep velocity stable is to keep availability stable. When the availability between teams is equal, then the other comparison metrics will work.

Conclusion

Comparing teams is not about punishing the low performance, but about increasing the motivation and spirit to compete and deliver more. That’s why those metrics should not be visible to individual team members. By keeping control of the comparison metrics above with indirect guidance to scrum masters, you can give equal grounds to teams to compete with each other.

The tooling

Scrumpy Planning Poker is a great tool to use for providing honest estimations and achieve a stable velocity by keeping the whole team engaged. You can start your first Scrumpy Planning Poker session right away!

Try NOW!