One of the core ideas put forward by the Agile Manifesto was for teams to welcome changing requirements from the customer, also when they're already well into the project's development. Arguably, it's one of the ways Agile gives teams a competitive advantage. More openness to what the customer wants should translate into products better fitting their purpose and happier clients.
We believe that, for a software development company to remain successful, embracing fluid requirements is a must, not an option. Leaving the clients who do not know what they want out of the equation, it's worth noting that the most common reasons for changing requirements are: a market change, a mistake in writing them down originally, a defect in the existing product, or a change in the law that the product must abide. None of them is within the clients' control. Hence, unless you open up to fluid project requirements, your clients will likely take their business elsewhere.
But achieving satisfying results and keeping a team sane is not easy when the demands keep changing. What strategies should you employ to respond well to changing requirements?
Don't spend too long estimating and planning out a project
Place the few core requirements, described well enough for the developers to understand, but with no excess frills, on the project Kanban board. Let the team members pick one task each, or one for each pair, depending on how they choose to work. It's better not to assign tasks to people in a scenario where changes are expected.
Keep batch and tasks size as small as possible
Not spending any time on work that is not crucial for a feature will be imperative to limiting waste. Focus only on the core idea of a request. That, combined with keeping the general batch size as small as possible, will keep tabs on the amount of work that is later recognized as unnecessary.
Set and honor the WIP limit
Work in progress limit is an easy way to keep work quality high and project waste low. A good rule to follow when setting the limit is for it to be smaller than the number of people on the team. Respecting the WIP limit will maintain order in the project, stopping the incoming change requests from piling up in front of the developers, causing a sense of urgency and instability. The projects' trajectory will, inevitably, be unstable since the demands can change at any time. But the perceived progression of items on the board will balance out the chaos.
Make the process flow visual for all involved parties
If you're going to take a shot at managing the process and keep the evolving requirements in check and waste under control, the flow must be transparent and accessible to everyone: the team, the clients, and management. Visualizing the process and every individual task on a Kanban board will have a few key advantages to the changing requirements subject matter. It will make it clear what items got done already and which are still in the backlog. So, if the client has a change of mind about a feature present on the board, they can edit the unstarted card to request the new design. Or, they can halt the development of a no longer wanted thing to minimize waste.
Another advantage is that showing the scope of work already done to the client, in the light of them having a change of heart about the core idea, will make them aware of the cost already spent. It will either make them think twice about requesting the change or, at the least, better prepare them for the bill value at the end of the project. To make the cost clear, feel free to use your Kanban Tool boards' custom fields showing a task's hours worked directly on it.
The fundamental point in opening up to fluctuating project requirements is to have the changes themselves not cause havoc nor create new organizational problems. If this is what it looks like for your team - an alteration in the requirements breaks your process and costs you tens of working hours of waste, you are not doing it right.
A well-known issue with teams staying open to accept requirements updates throughout the project is the impossibility of estimating the final cost. It can be worked around by keeping the projects themselves very small so that the general estimate and total cost differences are not as stark.
But an advantage that accepting fluid requirements gives you is more important than the downsides. If you'll only be working on projects with demands set from start to finish, so those where the entire plan is clear and available to the client - what's bounding the client to you? They can take the schedule to a more affordable developer or outsource it at any time. For as long as you're open to working with them, not just for them, they will stay satisfied by having their completely custom needs met. You'll be giving them a bespoke service, not a closed-off product that may no longer be what they need after the time it took to produce it.
Why is transparency key to project success?22 Jun 2021
When working as a team, it can be challenging to arrive at a shared conclusion and an agreeable result, to put it mildly. And, where teams working on the more technical aspects can rely on a binary classification of the issue - something is either done right, or it's not, the groups that...
What tangible effects does using Kanban boards have?30 Mar 2021
A typical storyline behind teams wanting to start using Kanban is that they received an incentive from the management to "get more Agile". And, let's be honest, this is not at all a bad reason to start! Chances are, that journey will not end there - but that one team using Kanban for their...
How to set achievable goals?10 Feb 2021
Are you familiar with the dread that a seemingly unsurmountable task can cause? Some types of goals are impossible to estimate in time and effort, for instance, the path to changing a career or pivoting the entire premise of a business. Still, both of these things are happening every day, so...
Feedback Management with Kanban18 Aug 2020
Progress happens when you find a solution to a problem, that removes the problem from happening again, right? A leading factor making this possible is taking note of both your colleagues' and your stakeholders' feedback. First and foremost, we're concerned with their comments on the matter of...
6 Remote Work Tips & Best Practices to Work From Home18 Mar 2020
With the coronavirus spreading, remote team-working is becoming the recommended approach for all those businesses that can facilitate it. Take a moment to see how to do this well with your team. Find your spot and stick to regular working hours For many of us working from home can be...
Kanban Tool is 10! Well... 12 actually!19 Dec 2019
We started working on Kanban Tool in the beginning of 2008. Later that year invitation-only alpha was released. While Kanban Tool public beta along with our website kanbantool.com was released in January 2009 making Kanban history. Kanban Tool is one of the very first services, that proposed...
Get Ahead of Work-related Stress!27 Nov 2019
It is well established, common knowledge that stress increases the risk of all kinds of diseases, and greatly contributes to burnout. Have you taken any action against work stress affecting you? We'd like for you to at least consider the below strategies. Put effort into creating good work...
Overcoming team dysfunctions15 Oct 2019
In managing day to day team activity, it can get difficult to keep tabs on how well a team is actually doing. Completed tasks count on the team's Kanban board may not tell the full story, seeing as quantity alone says nothing about quality. Analyzing how many have return from Done to Doing -...
Introducing User Groups for better access management03 Oct 2019
We're happy to announce a new, better way to assign Kanban board access to team members. Rather than having to share each board separately with chosen users, you can now tag people as members of specific user groups. Then, simply decide which boards are shared with what group and in what...