From requirement elicitation to development journey

• Have you ever been in the requirement jungle or have ever complained about a lack of requirements?
• Have you ever experienced a never-ending refinement or planning meeting with no results?
• Have you ever struggled with unpredictable estimations which disabled the proper roadmap preparation?
• Have you ever been lost in your backlog like in the black hole?
• Have you ever had a concern about how to describe the requirements to be ready for development?
• Have you ever wondered how to design the product specification to be understandable for both – business and technical audiences?

Sounds familiar? … We have gone through this.

On a daily basis, we cooperate as a Product Owner and Functional Analyst of one product in a dynamically evolving connectivity domain. In the surrounding of multiple projects and production installations. In such circumstances, together with the development team, we build the product, meeting all conflicting requirements, both coming from the standardization body and from existing and new customers, internal and external.

Throughout our professional careers in different companies, we have struggled with all the mentioned above difficulties and in the current team, given the outputs of the retro meeting we were constantly trying to improve. After multiple numbers of iterations, attempts, testing different ways, we have finally invented our own methodology.

Once we had a dream…a dream of an efficient refinement meeting, 30 minutes planning sessions, well-structured and documented requirements, controlled and clear backlogs, good control, and traceability, always knowing where we are and where do we go. You may have the impression that this is just a dream of a madman, but let us take you on our journey through business and technical world cooperation and show you the proprietary tools and tricks that helped us address all the needs. And made our dream come true. Let the journey begin – from requirement elicitation to the development (…)

Business need definition

Requirements gathering and prioritizing

How to avoid catching yourself in the requirements jungle on the one hand and lack of requirements on the other hand?

Most of the Product Owners and teams experienced tough times when requirements were coming from several sources – external business requirements, internal technical ones, additional demands, potential issues, and bugs. All these reported by different channels – different chats, emails, CRs, developers’ concerns, backlogs items registered by everybody from inside and outside of the team. How to control this and do not go crazy?

The requirements coming from different sources are structured and gathered by the source. They are waiting in the dedicated, listed foyer below, where they are managed properly, to prospectively become the product backlog items:

• roadmap items put in proper order on the timeline and periodically reviewed,
• structured backlog (epics, tasks, and subtasks)– the team is responsible and tasks can be registered by team members but only one person is accountable (PO control and visibility),
• technical debt epic – the technical debt items are identified on the daily basis by the dev team members and are raised in the backlog in this dedicated epic. It is then managed by the Technical Debt Committee. This Committee consists of dev team members and gathers frequently to discuss and analyze the technical debt epic items, describe the details, and prioritize. Then the items are waiting in the queue (the technical debt top priorities backlog) to be picked out to the particular sprint backlog when the PO finds the space for them,
• external channelhere all external questions/asks/needs/issues are raised and managed appropriately. Each item is reviewed initially by the PO/FA or other dev team member and after either answered or rejected out of hand or qualified to further processing (used to protect the product backlog and keep good visibility),
• bugs triage sessionsto discuss all reported issues (periodic review),
• customers CRs table to store the status, history, and the related deliverables,
• PO& FA Kanbanwhere all the ideas that pop out in our heads are registered not to be forgotten and kept for further processing – they may or may not become product backlog items.

From the above foyer, the requirements are sensibly picked out to be further processed, if reasonable. 

Roadmap management

How not to struggle with unpredictable estimations and improve roadmap creation and maintenance?

Roadmap is the main PO focus – the main trick is to build it with a good level of accuracy and predictability. It is not hard to create the roadmap but the challenge is to build it and be sure that it is doable.

Yearly roadmap is prepared in advance, items are roughly estimated in advance as well – you may ask how we can foresee the workload of something not yet described in every detail… well here comes another proprietary solution – budget consumption tracks which give the historical data for future estimation by comparison.

How does this work?

The roadmap is strictly mapped to Jira epics and those are also mapped to Time tracking App where all team members report their daily work. Given that we get very precise MDs (man-days) consumption for each roadmap item. Hence the team gets historical, accurate data for further estimations (when using estimation by comparing). Thanks to it, we are able to deliver the expert estimations in the scope of our product in a more efficient and accurate way (in advance).

Then the closer to the development, the roadmap items estimations are reviewed and re-estimated (if required) – the idea is to have more mature estimations before quarter commitments.

Each quarter the roadmap is approved by stakeholders and by the development team (represented by Team Leader or by Architect) to avoid the risk of overcommitment and – in the result – delays.

The roadmap is maintained and reviewed periodically to check the execution status. The list of all items for the future year/s is kept and maintained. Each item has:

• Name
• Priority
• Related component
• Description
• Benefits
• Estimated workload
• Consumed workload
• Consumed – Estimated (to show the level of accuracy)
• Status

The list is dedicated to being used by stakeholders and the team.

Backlog management

How to avoid being lost in the backlog like in the black hole?

The main goal is to be always oriented. In case the backlog is huge, the product has many components, few teams developing the same product, supporting inactive backlogs will do perfectly. We use sprint backlogs per team where each team can deliver a working part of a product (hence, each team is packed with each role representatives – functional analyst (FA), quality assurance engineers (QAs), developers (DEVs)).

Creating the drafts of future sprints backlog (one or two) leads to smooth planning – during refinement the team sees what the coming items are and makes sure that those are technically refined, estimated, and ready for development.

How to construct a good sprint backlog? – take a portion of the roadmap, three spoons of CRs, and a pinch of technical debt or a bug.

How a PO can pick the most urgent technical debt issue? Well …the Technical Debt Committee stays in charge of a dedicated sprint backlog for this, where items are prioritized and ready for development.

How to keep the focus on the most urgent topics, most critical bugs? Here comes the already mentioned bugs triage session to review and prioritize periodically all reported issues. All bugs reported externally in the dedicated EXT channel or internally directly in the backlog – are reviewed frequently during Bugs triage sessions. The PO, at least one QA, at least one FA, and at least one Developer shall take part in each of such sessions.

During these meetings the decisions are undertaken, the bugs are further processed (assigned to coming sprints, assigned for further investigation).          

Business refinement

How to deal with requirements specifications?

How to describe the requirements to be ready for development and how to design the product specification to be understandable for both – business and technical audience?

The requirements qualified as the backlog items are analyzed and specified in the Functional Requirements Specification (FRS). The specification is prepared to be understandable for both – business and technical audiences. That’s why it’s organized as follows:

High-level solution description:

• general requirement overview – introduction with the business need clarification (summary dedicated to the business audience),
• business requirements – coming from the business need which was described above,
• system requirements related to the business ones,
• use cases with the description and mapping to test cases.

Low-level solution description:

• Low-level use cases – solution – specification with UML usage if required e.g. API functions specification – the base for development.

Each requirement has a dedicated section in FRS, which is linked to the corresponding analytical backlog item and to the low-level description specification. The requirements in FRS are versioned – each version of the requirement has a dedicated description branch in the requirement-dedicated tree. Each requirement has info about release status to indicate whether the change was applied to the product and in which version.

This enables requirements evolution tracing. Requirements are numbered and these numbers are used in the backlog to tag particular backlog items. Also, the use cases (specified in the scope of particular requirements) are linked to the test cases. These all enable requirements tracing during the whole lifecycle – from creation, through analysis, implementation, testing until the release.

In the end, it is very important to assure that from both – business and technical points of view- the specification is valid. That is why additionally there is a validation and verification process in place. The validation and verification of the described requirements are performed by PO and dev team members. After that, the specification is finally approved and ready for technical refinement.

Refinement management

How to deal with inefficient refinement meetings

Kick-off refinement

If you would like to avoid inefficient refinements with no results at the end, during which nobody would like to lead the topics, nobody is prepared. When there is no plan, no idea and you are spending many hours discussing each backlog item and trying to estimate, then see how we have managed it in our team.

To keep the focus, we have started with smaller groups – functional analyst, product owner, and technical leader (Architect) – trying to refine and prepare functional documentation before the entire technical team is involved – that saves a lot of time also for developers. Each group of team members is being engaged in the proper stage of requirement processing when the appropriate fundaments are established. Then we are ready to expose these to the team and for that purpose, we have a dedicated kick-off refinement (introduce the dev team into each new requirement topic from a business and functional point of view).

Kick-off refinements are organized according to the need – when the requirement is analyzed and its specification is ready. The PO, supported by the FA, leads these meetings. The whole dev team participates in it.
Given these meetings and the mature functional specification (FRS), we allow the dev team to get familiar with the item, we can address all uncertain points so that the team can easily jump into the matter and continue the process with technical refinement (implementation proposal and estimation).

Technical refinement

Frequently conducted Technical refinement meetings are very consciously planned, which is very important from an efficiency point of view. Based on different sources – roadmap, committed timelines, confirmed CRs, and technical dependencies consultation with FA, PO queues the items for future development. The goal is to have the coming sprint backlog pre-prepared, refined, estimated – the future draft sprint backlogs shall consist of items ready for planning. Developers and QA-s are mandatory participants for this meeting and optionally FA – needed to answer some functional questions or elaborate on functional specifications. During these meetings the team – using FRS and the knowledge transferred during kick-off refinement – divides the items into DEV and QA-s tasks describe the implementation and all related important details and estimate the tasks. Such prepared tasks are ready for planning. All described above pre-preparations (requirements management, smaller groups of pre-refinement, kick-off, FRS, validation, and verification) lead us to a further efficient process.

Planning

How to deal with never-ending planning events?

Long-lasting planning – introduce the scope of the sprint to the team, discuss, estimate, and plan – seems a lot for one meeting. As result we either do not start the sprint because the team couldn’t commit, or we start but there is a huge risk of delay because the tasks are not properly estimated and not clear enough.

Hard to keep a big group of participants active, collaborative, and focused.

This is a description of planning events, which are only bad memories for us.

Thanks to well-prepared DEV and QA tasks, the planning is only a matter of routine. Now it is a real pleasure to take part in it, as:

1. We know the velocity and the forecast capacity of each development team group – DEVs , QAs and FAs – thanks to the team performance metrics that we gather.

       Team performance metrics help the team:

• check the current sprint goals and tick them out when done (goals realization monitoring),
• track retro meetings output action points (to keep constant improvement),
• keep each sprint historical data along with PO’s feedback after each,
• store velocity statistics to calculate forecast,
• keep main team statistics (velocity, scope change, work left per sprint),
• prepare the next sprint capacity forecast (helpful for smooth planning).

2. We have well prepared and estimated tasks, thanks to described above efficient refinement.
3. Given all these collaborative preparations (refinements, forecasts, pre-prepared sprint backlogs) Product Owner is could easily prepare the sprint backlog according to the roadmap priorities.

The recipe for 30 minutes smooth planning:

1. Make sure to have pre-prepared sprint backlog (before the planning all items in the sprint backlog must be estimated and ready for development – establish with the team the definition of READY for DEVELOPMENT.
2. When the current/active sprint comes to the end – make sure to input work left for each item that will be dropped to the coming one. This way you will be able calculate sprint estimation vs capacity easier. Dropped issues have SP (story points) where some might be already consumed, so this way the work left gives exact impact on the next sprint.
3. When closing the sprint, drop all unfinished items first to supportive backlog dedicated for dropped items (calculate the work left from there and distribute items to new sprint – during the planning).
4. Create new sprint capacity forecast (use team statistics and team leaves calendar to have precise estimation).
5. Set a sprint goal in advance.
6. During the planning, expose the goal to the team, check the forecast capacity vs sprint estimation + work left estimation, leave buffer if required and get the commitment from the team.
7. Done.

Summary

Now our product world and the journey “from requirement elicitation to development”, looks very pleasant. Moreover, we have created this world together with the whole product team.  This is the fulfillment of some of our dreams, not all of course because we are constantly dreaming, improving, and progressing, trying to achieve more and more.

The dreams about good coexistence and cooperation of two worlds inside the product team – the business and technical world.

We are representatives of both these worlds. Maybe exactly this, that we come from “2 other sides of the mirror”, determined that we have reached this point – with current tools, rules and processes launched.

Maybe without the willingness to strongly cooperate and not only stay in the relation a principal PO and a fulfiller FA, achieving this will be not possible. As the roles in the team should complement each other and here is PO and FA like racing driver and his pilot – the first one sits behind the product wheel and knows exactly “the what”, “the why”, and overview of “the how”, while the second one knows the overview of “the what” and “the why”, and every detail of “the how”.

That is how the technology and business world coexistence makes it possible to reach the impossible and makes this constant journey smooth and efficient.