Validating Our New Approach To Requirements, Project Scheduling, and Forecasting

[Dharmesh Barot]

Hi,

We are a digital agency and due to the nature of our industry we have to be Waterfall/Agile hybrid.

Current process

    Business Requirements (BRD)

1. We write business requirements
2. Business requirements help to define scope and estimate implementation in hours
3. Various roles (backend dev, frontend dec, integrations, etc.) estimate using business requirements, but create their own breakdown items for estimation
4. This is done to provide our client with an implementation budget and get the project
5. However, our estimates are way off because we don't know everything, and can't possibly know everything.

    Functional Specs (FSD)

1. Once we win the project we write our functional specs using business requirements
2. Epics are identified from business requirements, which are planned and prioritized into Sprints (at least for first few sprints)
3. Functional specs are written in the form of user stories and entered into Jira as tickets
4. Team reviews the tickets, creates sub-tasks, and estimates the sub-tasks (we don't estimate stories because sub-tasks are broken by roles, and project managers need to know each role's demand, so they can resource them appropriately)
5. Since we don't have all the stories in the backlog it is difficult to forecast a date range for milestones or launch

Question we are trying to answer

1. How can we improve our estimates knowing we need to provide a project cost to win the project?
2. How to create traceability from business requirements to functional specs?
3. How to identify requirements with large variance in estimation between business requirements and functional specs? 

Few things we know could help but can be a challenge

1. Write more granular business requirements as user stories (yes, I understand they are essentially conversation reminders about requirements). This could consolidate BRD and FSD, but may be seen as too much of a change. Need to take baby steps to get here
2. We may have to continue using BRD and FSD but writing granular business requirements will help to understand the needs better
3. Use affinity grouping and relative sizing for initial round of estimates. Challenge is this may be perceived as less accurate than what we already do
4. All roles to use the same business requirements and breakdown to estimate
5. We are also considering moving from Scrum to Kanban, but unsure if we need to fix/improve our foundation first.

What would you do if you were in my shoes?

[Tom Kakanowski]

TL;DR I don't see a great outcome for you here I'm afraid, basic mismatch between your client engagement process and your implementation process will lead to estimation inaccuracy.

BRD to FSD traceability is a potentially small part of requirements management.  You could enter requirements into a Jira project, enter FSD specs, user stories, job stories, whatever you need into another Jira project, then link the FSD records to the BRD records.  I've done this before, but you run into roadblocks pretty quickly due to the limitations of Jira.  Jira is neither an agile management tool, nor a requirements management tool, its a bug tracking tool that people bastardize to do other tasks, and as a result it does not do them well, and you run into the tool limits fairly quickly depending on the maturity of your organization.  But on the upside, if your needs are simple, then the tool can do both simple requirements management and simply agile management for you.  The limitation that constantly imposes itself here is that, while Jira is very extensible horizontally (ie add tons of attributes/columns), it is very limited hierarchically, which is where you often need strength with requirements hierarchies.  If your BRD can be expressed in a very flat way (ie no more than 2 levels deep), then you can achieve this through Jira.

Moving from Scrum to Kanban has no impact on this, but if you have multiple teams, and are managing portfolios of multiple programs, then you will likely end up consider moving to Kanban at the program level.

Sizing is a function of team stability and maturity, as it is a reflection of reliable team velocity.  If you are working with a single stable mature team, then you might be able to convert sizing into estimates, or extrapolate out based on velocity for sprints to complete required backlog, which also provides you a basis for estimation.  This approach is unreliable though, as a change in team composition, use of multiple teams, or matrix teams can all lead to significant inconsistencies.  In my past, when dealing with this scenario.  It also assumes a very complete definition of done, so team maturity comes back into play here too.

In the end, I don't believe your business model can, or will align with your agile model, and as a result of the impedance mismatch between these two models, I don't think you'll find a nice way to drive estimation through Scrum.  Your business model is waterfall, specification driven, and driives contractual compliance in respect to delivery, features and cost.  Your delivery model is employing Scrum today.  Scrum is about iterative development focused on business value.  It assumes that BRD driven processes fail because 40% of BRD driven requirements fail to deliver value in the real world, and instead is focused on iteratively delivering value to the organization, without commitment to specific timeline.  Value to your organization is implementing the FSD in its entirety.  If you were doing an MVP with a client, and had a dynamic relationship with the client, Scrum would fit better.   Kanban does not solve your problem here either, it just reorganizes work into states based on resource capacity instead of sprints, both being prioritized by something, ie value.  So, IMO, you need to abstract your implementation approach away from your approach to client engagement, and in essence wrap your implementation in a waterfall (assuming your client wants hard answers to what is being delivered, timeline, cost).  This is both a common and a difficult challenge for organizations, as larger groups who have waterfall project models and executives who want the same kinds of answers and commitments as your clients are wrestling with implementation teams doing things in Scrum, and that misalignment causes many problems until alignment of some kind can be achieved.  In those cases though, its more times than not that the executive shift and demand changes as a cultural understanding of focusing on value delivery instead of fixed work occurs.  I don't perceive you have that option.

So, as I mentioned earlier, assuming you want to implement in Scrum or Kanban, but your client engagement process in essence demands waterfall, wrapping the implementation with the look of waterfall could help, but is not an actual solution.  If a team took an FSD, estimated 6 sprints, were a reliable mature team with a stable velocity, then you could take that information, team composition, add some tolerance factor and end up with a gross cost and timeline.  But there is a lot of room for error, and your request was to improve estimation.

The one plus out of this is that backlog grooming, depending on size and maturity of the team doing the grooming, should allow identification of requirements with large variance in estimation between business requirements and functional specs, but your scrum master would have to try to capture that, as the basic process would see the team come to consensus, whereas you want to capture the variance of estimation from team members prior to that consensus.

Sorry not to be of more help!