Skip to main content

Frustrated with continuous requests for enhancements on a project? Maybe your company is pushing for more lean or agile practices? Perhaps you’ve tried running in agile before, but haven’t delivered. There are many great habits that product teams can utilize to help streamline delivery and ensure project success.

 

One of these habits is introducing agile in the workplace. In its simplest terms, Agile is a methodology that takes an iterative approach to projects, creating a continuous feedback loop with stakeholders, and assuring that value is delivered to customers by establishing trust and communication, delivering often, and allowing for flexibility. 


*Agile terminology comes from
Scrum Glossary and SAFe website

 

To organizations that do not have a clear understanding of agile principles, the thought of implementing these practices can be daunting. There are a number of ways to incorporate agile practices into daily operations. Starting small and working towards a full-blown agile solution typically works best for companies hoping to adopt agile practices. Below are just a few examples of modifications that can be made to existing processes to help streamline project delivery.

 

The Agile Process explained…

The agile process typically starts with requirements gathering. During this phase of the process, product managers and product owners meet with stakeholders to understand their desires. These desires or asks from stakeholders are translated into Features. Once a list of requirements has been gathered by agile leaders, they work with the team to prioritize these requirements and plan out phases of work. 

 

After requirements gathering, agile teams will sit down to groom their backlog – the Features they’ve just created from stakeholder meetings. The process of backlog grooming typically consists of one or more of the following activities:

  • adding additional detail to describe the purpose of the Feature, 
  • creating proper acceptance criteria to help the team understand when the Feature can be moved to a “Done” state, and 
  • assigning business value, time criticality, and level of effort to the Feature

 

After a Feature has been established and groomed, product owners sit down with their team to break Features out even further into user stories. These user stories are what the team uses to track how their day-to-day work contributes towards Feature Completion, as well as what the team uses when prioritizing work for upcoming iterations – usually called sprints. Typically teams will conduct sprint planning every two weeks – or at the end of each sprint cycle. 

 

Prioritizing Work

While there are many ways to prioritize work, an easy and effective way is to use a simple calculation to prioritize the Features. This calculation is called the Weighted Shortest Job First (WSJF). ImagineX has found this method of prioritization to be especially effective when there are many stakeholders. 

The Feature with the highest WSJF score is considered the most critical while the Feature with the lowest score should be regarded as less critical for immediate efforts. Once the team has determined which Features have the highest prioritization, the Product Owners will work with teams to ensure that each User Story has assigned story points (level of effort required to complete a story).  

 

Planning Work

It is important to create a plan for tackling work to ensure that teams are not over promising delivery to stakeholders. It is the job of the product manager and product owner to understand and adhere to the capacity constraints of their teams. The easiest way to do this is to utilize a WSJF and simple capacity calculation. That can look a little something like this: 

In the above equation, each workday is granted 1 point for capacity. We are allocating 20% time for meetings, documentation, and other admin work. This leaves us with 80% time for hands-on development work. Baking in time for administrative tasks ensures that the team is allowing for ad hoc meetings they may need with other teams, stakeholders, or their own team scrum meetings. Accounting for time off also ensures that product owners are not over allocating development efforts when team members are available – thus helping to create a happier, more efficient working environment and mitigating some of the usual burnout or frustration that employees may face when planning activities have not taken place. 

 

Once Features have been prioritized, stories have been created and capacity has been determined, we can start planning work for each sprint.

 

It is important to note, however, that when loading work for following sprints, product managers and product owners do NOT load each sprint to 100% capacity to allow for some flexibility in work, as things can change rapidly. Agile principals say it is best to load to 90% for the immediate sprint, 80% for the following, 70% for the subsequent. This will allow for availability to incorporate feedback from stakeholders as teams iterate through projects. 

 

How Can You Incorporate Agile Principles on Your Project?

Implementing agile requires a lot of work up front, but in the long run it can be very beneficial to your company when implementing automation projects. 

 

Define Your Scope & Identify Potential Blockers

A successful data project starts with well-defined requirements. By gathering requirements up front, understanding pain points, and documenting all intricacies in the process, teams will be able to anticipate any potential roadblocks and identify areas where additional assistance may be required. This will help the team understand what meetings might be required and design the automation process in a way that bottlenecks do not become major impediments to the process. 

 

Plan work using the WSJF scoring and capacity planning formula above. Make sure to adapt the capacity formula to something that makes sense to your team. 

 

Test Frequently, Release Often and Request Feedback Early

Releases will be iterative – a deployment might not be perfect and code might still need some cleanup.  By gathering feedback quickly and early in the process, teams are able to pivot efforts without losing too much time if stakeholders requirements change or major issues are identified during the build process.

 

By implementing these practices, teams can be more effective in the planning, development and deployment of projects and allow for more visibility and collaboration with stakeholders who may play a key part in the funding and expansion of project teams.

 

Manu Brune

Author Manu Brune

More posts by Manu Brune