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 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!

Tutorial

April 30, 2018February 10, 2021

Sheepherding story points

Introduction

Most of the time estimating with story points is neglected and performed in chat rooms where all messages are visible, or verbally when everything is audible. Knowing how other people voted for a story estimation twists the outcome of voting and the result is not correct. An incorrect estimate repeated for several stories leads to wrong business plans and delayed or canceled deliveries. Let’s investigate what happens in an open vote.

The characters in voting

There are several characters participating in an open estimation vote. Depending on who goes first, the story gets estimated differently, but mostly far from the honest estimate. Why does the open vote make it that significant who goes first? Because of the sheep effect, other team members tend to copy the original estimate.

The “I know it all” team member

Every team has at least one member who thinks he/she has the most knowledge of the system. Usually, this is the first vote since things are known. There are often overseen details though that can spoil the expectations. Those details can be discovered in advance, but only if a discussion is provoked. This cannot happen in an open vote.

The “I know it all” team member usually votes with a lower estimate than the honest estimate. Probably only this team member can execute the estimated story for that little time and only when he/she gets lucky.

The rest of the team members vote the same so at the end, it appears that the estimated task is easy and anyone can do it for the appointed time. Unfortunately, often this task is picked by other team members.

The “Introvert” team members

Usually, those team members are more than one and they are afraid to be the first voters. They expect someone else to vote first so they can repeat the vote. They rarely participate in any conversation for a particular issue of a story and reply only when being asked. The introverts vote second, just before the “I don’t care” team members.

The “I don’t care” team members

During implementing stories it is difficult to catch those team members, but during the vote, it is most obvious. They always vote last and repeat the estimates of the others. If the estimates are different, they announce the one that repeats most. The reason is that they don’t want to be asked questions why a lower or a higher estimate was announced. They never collaborate during the refinement session and desperately try to avoid any questions being asked.

I don't care and don't know — I don’t care and I don’t know team members

The Tired employee

Some of the team members just can’t stay focused for a long time and so they miss some important part of the discussion. For various reasons they lose context in the conversation and tend to give random story points to tasks or desperately try to find out what is the most repeating vote so they can copy it.

How to keep the attention during estimation

Estimation is important since only the honestly assigned story points can bring a project flawlessly to the release date. The most important part of the honest estimation is to never allow team members to leverage the sheep effect by using special estimation tools like paper cards or software.

The team members should never see each other’s estimates until they are revealed by the moderator. This way Introvert starts thinking, Mr. “I don’t care” gets interested and Mr. “Sleepy Tired” wakes up. The best question to ask, especially when deviating from the average voter is “why did you vote X story points”. This will provoke some conversation, some discussion with the moderator on the real implementation issues for the story. The close-ended questions like “would you agree” with X story points automatically lead to the useless answer “yes”.

With an estimation tool that brings some joy to the boring refinement session and requires each team member to stay awake and ready to discuss, it is no longer difficult to give proper estimations even to complex stories.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and properly estimate stories in Jira (and not only). It helps team member stay awake, have fun and estimate honestly even the most complex stories. You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The following video shows how quick and easy it is to start a refinement session, personalize the theme and language and estimate stories honestly. Scrumpy Planning Poker is fun and engaging!

April 28, 2018February 10, 2021

The 10% scrumban rule for every sprint

Introduction

It is a common practice for many Scrum Masters to commit to the exact capacity displayed in the Jira Portfolio. This is often not the right approach and leads to failed sprints. The simple question is why this happens when the capacity calculations are so punctual?

The rush to deliver more

Product owners tend to push towards increasing the velocity after every successful sprint which looks like a natural reaction to the latest achievements. As the team completed a certain amount of story points last sprint, it is expected that it can complete more the next one. And this is repeated until a sprint fails. This push is kind of urge to test the team’s limits. Our experience shows that this is counter-productive. In the end, it appears that this demotivates the team as they see every future sprint as doomed.

The hectic end of a sprint during a delivery rush

When the team’s capacity is calculated to cover exactly one sprint, any delay or materialized risk is reflected by urging team members to work in a hectic rate at the end of the sprint. This leads to actually delivering less than promised due to the stress that something is going wrong. That’s why this rush at the end of the sprint should be eliminated at all cost.

Let the team deliver more by its own will

The velocity can be increased by adding a 10% of the capacity as a buffer that is used to work on tasks not included in the current sprint. Those tasks are fulfilled in Scrumban mode, i. e. from the backlog in Kanban mode during the sprint. It is used as a risk buffer and also to let the team complete its sprint (or at least the sprint goal) a couple of days before the end. Those tasks can replace a problematic task in the sprint (e.g. when there is an external dependency that threatens the sprint). The 10% capacity will be delivered extra, on top of the planned capacity and this will reflect un-materialized risk, e. g. the risk was averted. In case something goes wrong, this buffer will be exhausted, but the sprint goal and commitment will be met. This extra capacity in Scrumban mode should be monitored and if it goes to 20% for example, it means that it is time to increase the team’s velocity by 10% and still keep the 10% buffer.

Our experience shows that this is the time when employees work without pressure and contribute the most. This makes the increase of velocity possible, at the will of the team, without the urge from outside and with less stress. This way, the velocity increase is natural and desired.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and properly estimate stories in Jira (and not only). It helps in avoiding the Big Rush at the end of the sprint and keeps estimates exact by provoking honesty in story estimations. You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The following video shows how to integrate the Scrumpy Planning Poker application with Jira and let it edit and estimate stories on your behalf, quick and easy. Scrumpy Planning Poker saves you time!

April 14, 2018February 10, 2021

The importance of predictable velocity

Introduction

The predictable velocity is the ability to always know the volume of work that will be implemented by a team for a given time based on team’s availability.

The problem of varying velocity

When velocity varies between sprints, planning the release of a project becomes a tough process. It is never known when the tasks will be delivered and so the whole scrum process is broken. The sense of chaos is everywhere and that doesn’t help in improving team’s motivation.

Usually, the varying velocity is caused by the fact that individual team members try to deliver the best they can and they promise more than they can fulfill. Unfortunately, in a collaborative environment with a development process that is well set up, there is a bit more than just the straight-forward implementation of a task. Some team members get lucky and land on tasks that can be implemented relatively simple, but others hit a problem nobody has thought of in advance. In the end, during one sprint the team has a higher velocity (due to finalizing carry-overs), while during another sprint the team has a lower velocity (and cause carry-overs).

Having carry-overs causes the feeling that the job is not well done, the team can do more, but always something happens, something unpredictable. The management raises feels the problem, sees the failing deadlines and this creates a tension among team members.

The common problems in maintaining predictability

The problems depend on the project specifics, but many of them are common to all types of projects and will be addressed here with appropriate solutions.

Expect the unexpected

There are some tasks that require research prior to starting. Imagine, for example, some feature that requires interaction with a third party company that may not immediately respond when it is needed. Or this can be a feature that actually cannot be implemented in a straight-forward way due to a wrong understanding of the underlying technology when creating the task.

If such a task is added in a sprint without the needed research in advance, there is a high risk that it takes more time than expected and it will be considered “underestimated”. Some may argue that there is a need for a spike in advance to do a research on the subject. But how to know for which task a research spike is needed?

The only way is to start working on a task in advance. When the work on a task starts before it is actually planned makes it possible to find all issues before they actually occur. With such an approach, the task will be placed in a sprint only when it is absolutely clear and some amount of the work on it is already done.

Avoid fuzzy task definitions

Some tasks are defined in a way that they look ok-ish to their creator but do not include important details in their description. There are some implementation specifics that may seriously affect the task fulfillment.

Business people may argue that there must be no technical details in the task definition, but on the contrary, technical implementors find the business requirements too fuzzy to work on.

The solution is to have technical design documents in which the implementation task is referenced. Then it is clear from the technical point of view what exactly needs to be implemented.

It is also good to place technical details in the tasks’ description so that implementors know what needs to be done and some details can ring a bell for possible issues.

Decrease your capacity in a Fibonacci row

Sometimes team members go on vacation or there are holidays during the sprint for all team members. Training and other internal company events also contribute to lowering the team’s availability (the volume of work on project tasks). In this case, the capacity has to be lowered according to the missing people.

The velocity is considered constant, but it is calculated based on the average velocity of all people in the team. For simplicity, let’s look at the case when one person does one story point per day. If one person is missing for one day, the sprint’s capacity has to be lowered with 1 story point. If 2 people are missing for 2 days (2×2=4 story points), the capacity should be lowered with 5 story points instead. Finally, if 2 people are missing for 3 days, the capacity should be lowered with 8 points instead of 6 to include the dependencies risk.

Committing less capacity than calculated

Avoid dependent tasks

In many cases, one task is done by one person and it is a dependency of another task done by another team member. This causes in-team or inter-team dependencies. When the first task is not implemented on time, all dependent tasks are pushed back. This causes team members to idle and then rush when dependencies are done and this way misusing the precious time at work.

Dependent tasks can be started earlier so that when the next sprint starts the first critical tasks on which the others depend will be almost completed. This will reduce the dependency impact on the team’s velocity for the current sprint.

Estimate honestly

Giving honest estimates to tasks is a tricky task and it involves the attention of the whole team. Everyone should be careful and give estimates without being affected by other team members estimates. Only honest estimates can properly show how much time it will take for an epic to be completed and the release dates matched.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and make fun out of voting. It works on all platforms inside the web browser and can be used to define the story points for implementation tasks. You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The next video shows how easy it is to vote for a task and estimate it with Scrumpy Planning Poker.

April 14, 2018February 10, 2021

How to correctly estimate the release deadline

Introduction

An important aspect of project management is properly estimating the project’s release date. But how can you be able to predict at what date exactly, a big complex system can be delivered?

The estimation problems

To be able to deliver a project on time, the delivery date has to be properly calculated based on the correct tasks estimation. Estimating the tasks is usually a tough process, especially when you have to work with time-based metrics and provide an exact period in which a task should be completed. From a psychological point of view, committing to time for implementation of a task is hard and always prone to failure.

The problem with time

The reason why estimating time is problematic is relatively simple – the more complex the task is, the bigger the chance of not meeting the deadlines. On top of that, it really depends which team member picks which task. People in the team have different velocity and deliver a different volume of work. Due to the changes in the availability of different team members (vacations, training, etc.) sometimes a task estimated by the most performing team member can end on the desk of the least performing one. Then the nice Gantt charts become a mess – tasks become overdue and managers are always concerned if the project will be completed in time.

The resistance against time estimates

When implementors of a task are asked to give an estimate, there is always a resistance – if the estimate is not met then who is to blame? Also, when a task estimated by one team member lands for some reason on the desk of another team member, who is to blame when the estimate does not match the actual time spent?

All this leads to an unwillingness among team members to estimate tasks. This resistance creates difficulties for the management to properly estimate the delivery dates.

Using story points

There is an alternative approach to using time-based metrics for estimating tasks – using story points. The story point is not a fixed unit of work, but an exponentially growing relative estimate. The estimates are given by the whole team during the refinement sessions.

Sharing responsibility

By using story points, the whole team gives an estimate for each task. The estimate is accepted when all team members agree on it. This saves the discussion later who estimated it and how much time was actually needed to complete the task. There was an initial agreement between team members and responsibility is shared.

Estimating complexity

Story points are used to estimate the complexity of a task, including its external dependencies and any risk if something might go wrong. Since it is not a commitment to a physical metric like time, such estimates are given with ease by the team.

The smallest estimate

Since story points are relative, there must be an anchor from which to start. The anchor for the relative estimation is the smallest unit of work that requires some implementation effort. This is the least volume of work which the team is able to estimate.

The biggest estimate

Story points are exponentially growing to indicate that the more complex a task is, the more difficult it is to estimate it. Story points can grow up to the ∞ (infinite) estimate. The infinite estimate though is rarely used. The biggest estimate should be the largest unit of work that can be implemented by one team member on the average for one sprint. And the length of the sprint itself is evaluated by the biggest unit of work that can be done by a person on the average without losing control on the task.

The stories that are bigger than the biggest estimate

Some tasks are estimated by the team with higher story points than one person can implement within a sprint. Placing such tasks in a sprint will cause carryover. Carryovers are not good as they leave the feeling that the sprint is not complete and the job is not well done. To avoid this, tasks that are estimated higher must be split apart into smaller units of work and estimated again.

The story points velocity

The velocity can be measured in average story points per person per time actually spent on tasks (availability). The capacity is a metric for the volume of work a team can do for a given time based on its velocity.

capacity = velocity * availability

This metric can be converted to time and the release date correctly estimated. When the velocity is predictable, the project’s release date can be punctually estimated. Based on story points and sprints, the new fixed and predictable Gantt chart would look like this:

The tooling

The Scrumpy Planning Poker application is a useful free tool that allows estimating tasks in a collaborative way both by colocated and distributed team members following the Planning Poker rules. The refinement session is lead by the Product Owner (PO) or the Scrum Master (SM). You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The next video shows how easy it is to vote for a task and estimate it with Scrumpy Planning Poker.