Skip to content

5 Greatest Benefits From Just in Time Requirements

Just In Time Requirements are great for getting what you need first, enabling better user stories
Just in Time Requirements, or JIT, enable better requirements for the Agile team and help you build quality software. Part of good Agile development methodology for your team.

What are just in time requirements?

Just in time requirements, also known as JIT or JITRA in Agile software development. These are requirements where you determine the largest requirements first. Or most important, most valuable requirements first. This lets you start on work, and start to move forward. While figuring out more of the details around the large requirements as you work.

Don’t you ever struggle to get all of the information, and to get it before you even start the work?

Just in time reqs allow you to get enough info to move forward. Which is one of the most important ideas in Agile development. Helping you to get your requirements and user stories ready faster. As the goal is not to get all possible requirements information before you start. Instead, getting enough on the priority items, to begin the work.

Just in time requirements analysis is a pull system for work. Part of Agile methods is where you get just enough work for the sprint or iteration. Allowing team members to figure out portions of the work, then pull more when they need more.

Just in time requirements are really Agile requirements. Supported by processes like Vertical Sliced stories and good feedback processes for the team.

JITRA = discovery as you go

The basis of the just in time concept is that you discover just what you need for requirements, as you go forward with the work. Just in time requirements are agile requirements. You do not try and define all of the work, all at once. Avoiding the effort, analysis, and expended resources on defining requirements that are not in progress. Instead, you define the details for just the work you will be taking on.

Just in time requirements analysis is how you write better requirements. Because it allows focusing on the top requirements first. It’s also how you get more effective and efficient in writing requirements. This process will mitigate the issue of missed requirements. You will prepare information in priority order, in pieces, and thus prepare better requirements. It really is a better way of writing requirements, and it really is about doing less. However, you do the most important items first.

As a product owner or a scrum master, understanding this will help the team to work on the most important items first. As team members can always get work on demand when they need it from a backlog. This avoids the waterfall concept of working all of something before proceeding.

Or the idea of specific phases of work. These are requirement gathering, coding, testing, etc. Instead, you get enough work to proceed, finish it, then get more. This way work keeps moving towards the goals. Essentially, it’s a process to get enough to start the work and figure out more as you go.

escaping the build trap

Check out Escaping The Build Trap

The build trap is a problem facing many software and product development organizations. Understanding this problem scenario can help orgs to move past it and enable their own success. Just in Time Requirements are just a part of how organizations can escape the build trap.

Just in time requirements help the team

How do just in time requirements help the team? Just in time requirements is the idea that you don’t need to know all requirements to start work. You will learn the requirements as you work. The main focus is to have enough to start. Which really is fundamental to the Agile methodology as well. You need at least enough to start the work. However, you do not need to go get more than needed to start the work at that time. This is really just a good Agile process.

Get enough to be able to start your user story, not trying to get all info up front. That is the agile requirements gathering. User stories are more about communication and interactions with the teams and users anyways. They are less about rigid requirements, as that is more the Waterfall model. Prioritized work should be started, with the rest going to the product backlog.

Also, as you work, you will gain info and allow work to continue. It is all about knowing enough to enable more work to be done. It is not about figuring everything out upfront. Just in time requirements promote a good circular flow of work. That flow being, work is researched and understood. Then work is started. Lastly, work is completed, feedback is received, and the next thing gets underway.

Casting a net

A way I like to describe just in time requirements is like the following. Think of it like casting out a net. The net has holes in it, and won’t catch everything. It will catch the larger items. Those larger items are what you start with. IE, the large requirements.

You then use those to determine the remaining details. The smaller requirements, that you didn’t catch the first time. The net will catch larger items. You can continue to refine after that, to get what you need. You cast, work the items, cast again and refine what you pull back to keep moving forward. It is one Agile method that really helps deliver business value. Mostly, because items you would work on first are usually of higher value.

Pieces of a puzzle

Another example of just in time requirements is the puzzle. Modern Agile software development is often like solving a puzzle. Agile teams take a lot of pieces and they need to fit them together in the right way. Just in time requirements is similar to working the puzzle. In that, you start with large objects in the puzzle first. You build the large objects out. You often add the edge of the puzzle. Then you start filling in the smaller details. This is the same approach with just in time requirements. Figure out the big details with your stakeholders. Then fill in around them.

The pieces of the puzzle work well with the self organization of the Agile team as well. Letting team members decide on the team how they will work on the software project. Not having this decided by a project manager, scrum master, or others. I also am a firm believer that teams will better learn from the items they drive, so you will see much more continuous improvement from the team. Next are some of the greatest benefits from using just in time reqs.

Benefits of Just in Time Requirements

  1. Enable flow of the team. Work will move at a better pace for the team. There is a good flow on a team that practices this. When you know enough of the requirements, you can go execute on the work. After this, when more requirements are needed, you can quickly obtain them. Thus you create a cycle and enable work. The Agile team practices good collaboration when there is a good flow of the work. Team members are often working things together. Instead of in silos of their respective phases of work. Help build that cross functional team for your Agile project.
  2. Allow work to start sooner. With pieces of the work known, the team can start sooner. As opposed to having to have all of the requirements be known. It will take you more time to have all requirements, before starting the work. Thus you delay work. This is a change in mindset, to let go of needing to have more and just starting. You have to be ok with not knowing some things. Understanding Agile is about being flexible, backing up this idea. Which, another part of this is by allowing work to start sooner, you enable shorter increments. If work takes less time to prepare, you are able to get it into sprints and go execute. Which is part of an effective and timely feedback process. Check out information on the good feedback processes here.
  3. Less pressure on knowing all details. This attitude with requirements can take the pressure off the team. They do not have to know everything. If you expect to know all the details, you slow down the work to go get all of the details. Which slows down the team on their deliverables. It takes longer to find all the information and then start. Simplicity in the requirements enables the work to start. Adopting the just in time requirement process lets you start with less. Which, means team members don’t have to get more requirements in short sprint timeframes.
  4. Part of the incremental and iterative approach. This is part of the Agile approach. Use an inspect and adapt process. They build, learn from it, and build more. By having portions of the requirements, the team can build on it. They can learn from mistakes, adapt, and respond to improve. This is Agile delivery at its core. Building in smaller pieces of work. Implementing said work. Then learning from that work and continuing the process. With extra and new items going to the product backlog to be worked later on.
  5. Avoids wasted work in requirements. If you work ahead or try to get all the requirements, you could end up not using them. This could be for many reasons. You may no longer need the requirements. Or, you may have worked from assumptions that have changed. Lastly, it could be from technology changes, and the requirements are no longer valid. These are just some possible examples. Regardless of the reason, if you try to get all the details you could waste effort that is not needed. By utilizing just in time requirements, you cut down on these scenarios.

Just in time requirements analysis and Agile are complimentary

Agile practices and just in time reqs have many overlapping ideas. The thought is that you create work when it is needed and not all at once. Or that you release changes in smaller increments and do so frequently. Or how about planning for releases, in that you plan just for the smaller amount of work to be taken on and not all of the larger work projects to be done.

Agile user stories, documentation, planning, and collaboration all have similar approaches to the JIT requirement gathering approach.

In the end…

Just in time requirements are a powerful tool. They help you to get just the info needed to enable software and product development work. They help the Agile and Scrum team to deliver work in a more Agile manner. They help to build software products incrementally and in smaller iterations. Use it in your Agile processes to help your delivery today.

The practice will have you in a better on-demand work process and writing better requirements. It will help avoid waste and cut down on missed or incorrect requirements. It all comes down to delivering value and this is how you get requirements right. To enable delivering valuable things and correct things.

Remember, if you need help with missed requirements, just in time requirements will help. Just in time is how you do Agile requirements, enabling true software delivery. You will mitigate the issue of missed requirements and you will prepare better requirements. Whatever your software development process, adapting to a just in time requirements process will help deliver.

The process will bolster your existing Agile practices. Just in time requirements, simply put, are a part of good Agile principles for software projects. Emphasize their importance to take big steps forward. Be Agile my friends!

Additional reading and eBooks to help with just in time requirements

A lot of the Just In Time Requirement process relies upon a concept for breaking up your user stories in a specific way. This is Vertical Slicing and helps enable many practices in Agile Development.

Another great piece of information on Vertical Slicing is available here. Also available from TJ Rerob and Agile Rant on Amazon, here.

Also available on Leanpub, here.