Why I May Never Adopt the Practice of “Just-in-Time Requirements”

Author: Adriana Beal

The agile movement promotes positive change when it encourages teams to work together to create products that are fit for purpose with as little non-value-added activities as possible. Agile approaches embrace mechanisms for continuous improvement, and include practices that can be traced to Lean thinking, a management philosophy that aims to identify what creates value and eliminate all other activities. The core idea is to maximize customer value while minimizing waste–in other words, create more value for customers with fewer resources.

All is well until the talk extends to applying the “just-in-time” concept to software requirements. According to the November 2011 Draft of the Agile Extension to the BABOK Guide,

Within a sprint, business analysis activities focus on defining the requirements for the backlog items being worked on and the acceptance criteria for those items. This method is frequently referred to as just-in-time requirements gathering; developing only what is required for the current sprint and only done to the level of detail required to enable the team to build the product and acceptance criteria.

JIT applies primarily to repetitive manufacturing processes in which the same products and components are produced over and over again. (Raymond A. Jacobs).
Photo credit: inju

Agile approaches focus on building user stories or simple features that can be implemented in a short time period (usually 2 weeks). From my experience with complex software projects, detailing just the stories that are required for the current iteration can actually generate waste. Limiting the analysis to what is being produced in the next cycle prevents analysts from studying requirements in relationship to other requirements, and from seeing each piece of a system as a meaningful component of a working whole. Stories depend on each other, and in-depth understanding of their integration into a working system may be crucial to ensure that what is being built now won’t negatively affect what is going to be built in a later cycle, thus preventing avoidable rework.

In an agile project, unless I’m limited on time and resources, I will make a point of looking beyond what’s planned for the next iteration, and start elaborating related stories, even if they have been deferred to a a future cycle. This exercise often increases the value delivered by each incremental story implementation, helping ensure that underlying problems are being addressed in a way that will continue to work in the future, and facilitating the discovery of overlooked requirements–some of which may even require additional user stories to be included in the backlog.

Proponents of the practice of “reducing work in progress” will disagree with my approach of anticipating the creation of use cases, business logic, acceptance criteria, and any other requirements-related models I’m able to produce as early as possible in preparation for future iterations in my projects. The evidence I’ve gathered in past projects, however, is that making an effort to analyze and communicate the full picture of how each feature or story interacts with others (even when those will not be implemented right off) is actually a way of preventing waste. Taking the broader view to study the complete feature in detail, in parallel with working in smaller stories for immediate implementation, works for me as a risk-minimizing approach that helps stakeholders better understand the final solution while it’s being incrementally delivered, and increases the odds of the right decisions being made while the project is under way.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Ryan, when you say “anything that moves us away from BRDs”, I think it also depends on what you call a “BRD”. In my job, we use business requirements documents to capture the high-level requirements. Then, these requirements are decomposed only as needed for each release (so yes, I’m working partially in a just-in-time manner — at the product requirements level, not at the business requirements level). But having the BRD is of extreme value for a complex project in which there isn’t much uncertainty about the end goal — it helps ensure the right architecture is put in place to support the needs of the software product as it evolves, without causing a lot of costly rework.

    Thanks for adding your views to the thread!

  2. It was definitely interesting reading this article 🙂 I’ve recently written an article about the pros of this approach.

    As with anything – I think pragmatism if the best approach. IT/design/analysis is not the same as manufacturing – it is a creative industry. I think its good to implement some of the Just-in-time principles – anything that moves us away from BRDs 🙂

    http://rthewitt.com/2013/04/20/just-in-time-requirements-analysis-jitra/

  3. Hi, Steve!

    One of the great benefits of the Internet is that allows us to keep a conversation going without having to worry about time constraints :-). Thank you for adding your views. Well put. As with many things in life, “the virtue is in the middle”, and keeping a good balance between short- and long-term perspectives definitely helps us make better project decisions.

  4. Steve Cox says

    I’m coming into this conversation very late, but I’m compelled to contribute because I deal with many of the topics that this converstaion touches every day. As a BA Lead, I always try to convince BAs to learn as much as they can, at all times, about our business – business processes, how applications work with other applications (software solutions) to support those business processes, and how, especially, User Interfaces/clients work.

    I’m not saying I expect all BAs to know everythig (I certainly don’t expect that of myself). They should constantly be learning about the business (their company, the industry their company is in, and their comany’s competition) and software solutions. Also, I am not saying that this will be done at the expense of the deadlines for their current assignment(s).

    More often than not, project teams can only come to the best decisions for a moment in time, based on what is known at that time. Sometimes, that means the project teams know there are negative risks that come with the decisions that are made, and that the decisions have only short term benefits with longer term negative impacts. Often, because project team members focus on the short term goals, or only what they feel they need to know, the resulting project decisions are less effective than they could have been.

    By taking, or making, the time to learn about things beyond the assignment at hand, more informed decisions are made and BAs increase their understanding of their business and their business’ software solutions. aThis can improve the contributions that BAs make to their current and future project(s), and have a very positive impact on a BA’s value and personal brand. This can also lead to BAs being able to complete their deliverables faster and more accurately. In fact, this helps BAs to be more “agile”.

  5. @Tony:

    “And I think that is one of the important messages of agile re. just-in-time analysis – if you try to take account of everything and aim for the “perfect” solution then (a) it will take longer and (b) you may end up over-engineering for future requirements that either don’t materialise or else get de-scoped or changed. Hence the phrase “YAGNI” (you ain’t gonna need it).”

    Oh, I completely agree. It does not make sense to wait until you have accounted for everything and found the “perfect” solution. I always insist on accepting a certain level of risk and implementing requirements knowing that some of it may have to be reworked in the future due to the impact of adding other interrelated features.

    Mileage may vary, and that’s why the title of this article is “Why *I* may never adopt…” :-). For me, the balance has shifted more towards “inventory”, but I can see people working on different types of projects needing less of that upfront preparation.

    The type of system I work with is extremely big in size, has high complexity, dozens of points of integration, multiple regulatory implications, and lots of requirements that won’t drop out of the picture for various reasons.

    In my current project, I know there are several things that will never get de-scoped — for example, regulatory rules we have to implement to enable sales of products in certain places of the world in a B2C website. Those rules have been in place for years, with future dates by when you need to have certain functions working.

    The compliance requirements I’m working on are turning out to be more complicated than anyone imagined. So, starting to define the requirements 3 months before development begins is turning out to be a great decision for us. I’m still taking care of more immediate requirements in a daily basis, but in parallel I’m moving forward with these more complicated requirements. “Just-in-time” for these requirements is turning out to be 4 months before development starts, heh. And how do you know, if you don’t start to investigate as soon as an opportunity arises? ;-).

  6. Hi Adriana, great post (you can tell from the amount of interest!)

    I agree with the comments about keeping the balance between looking ahead and focussing on the current or next increment. And sometimes I find it a really difficult balance to strike.

    I was working on a system recently where I had to develop feature A for the next increment and I knew that it was related to feature B that was planned for some future increment. I had a hunch that the ideal solution would need to take account of both A and B. However, I also knew that, whilst A was relatively simple, B was much more thorny, and would take quite some time to work through.

    In the end I decided (with business agreement) that analysing the big picture (both A and B) up front would take too long, so we decided to just do the analysis for A, well aware of the risk that we might need to change it later. In that instance, the need to deliver A sooner was greater than the need to get it right first time.

    And I think that is one of the important messages of agile re. just-in-time analysis – if you try to take account of everything and aim for the “perfect” solution then (a) it will take longer and (b) you may end up over-engineering for future requirements that either don’t materialise or else get de-scoped or changed. Hence the phrase “YAGNI” (you ain’t gonna need it).

    I’ve had a bit of a mindset change on stuff like this recently. It does go against my grain to put something into development that I know might not be extensible or might need changing later on. Being the perfectionist that I am, I like everything I design to be “right”. But if an imperfect design means that the business gets *something* sooner, then that might be a good trade-off.

    Here’s another example from my last company. A project was building an app for a global company, to potentially roll out in many territories. The team gathered the requirements from the trailblazing territory (the UK, of course :)) and then they decided to halt progress for 3 months whilst they went all around the other territories to check their requirements to see if that might affect the overall solution, leaving the UK to wait another 3 months for their app.

    What would you have done in that situation? It’s not an easy answer, is it? Previously I would have done the same – to make sure the solution was “right”. Nowadays, I would think twice. I would probably build the app for the UK and worried about the others later. Would I have built it multi-currency? Not sure – again, tricky. But probably not initially. Maybe I would have tried to avoid doing anything too single-currency.

    So, in summary, I agree, it’s a balance – but a balance that has shifted more towards “just in time” for me.

  7. Hi Adriana,

    Great topic! I too see the need to detail things further out than the next sprint, and do believe that the Agile/Scrum framework allows for this quite well.
    While you have the “just-in-time” requirements, you should also be doing regular backlog grooming. As a product owner – and a BA – you can work in time to sit with team members during every sprint to begin detailing stories for the upcoming sprint(s). I believe that if you set aside the time to look at stories that are in the plan for the next 2-3 sprints, ensuring that you bring more detail to them the closer you get to proposing the story to the group for pickup — then you benefit from both “just-in-time” and the larger project view.

  8. @ Adriana – Great topic! Thanks for bringing up this topic for discussion.

  9. @Kent: Good point about teamwork. In my teams we tend to be very open about when more help would be welcome if people have the bandwidth, so typically we BAs don’t even need to check with the team to know if their help would be useful somewhere.

    Testing and training are good examples of things BAs frequently help with in my projects. However, being a team player and helping with tasks outside my area never prevented me from continuing to build an inventory of requirements. (Normally the opposite is true; as you train business users or help test the application, often new desirable capabilities tend to surface, which can then be documented and presented to stakeholders for future prioritizing 😉 ).

  10. Adriana, thanks for bringing up this topic for discussion. As others have brought up, the amount to work ahead is very context dependent. Working on the stories targeted for the following iteration is certainly important, as is having a good grasp of the overall picture. In fact I often model the overall problem and solution space and then identify user stories based on the changes needed to realize future state.

    Also consider that software development, especially that of the agile nature, is a team sport. So, if a BA finds that they have sufficiently described the upcoming stories with examples, they may want to consider checking with the team to see if others need help with something. It may be that time is better spent helping remove some other obstacle (such as backlog in testing), rather than working further ahead on analysis tasks. Being a good team member has the advantages of helping the team meet its current commitments and sharpening some skills aside from the traditional business analysis ones.

  11. @Johnny: wise words about achieving a balance and keeping a systemic view of the relationship between the requirements (something that’s often missing and creates so many avoidable problems). Thank you for leaving your comment!

  12. Johnny Fairley says

    Adriana, liking your work.

    I agree with your sentiments that is is unwise and potentially wasteful to not look beyond current iteration when considering value for the project or project vision.

    To mitigate the risk of potential negative affects of the working sprint being a silo is to use user story mapping. Mapping out your users stories ,or whatever you use, will tell the story of where the product is going and gives a broad view of the relationship between requirements. A story map (or Goal Breakdown Struture) is a visual radiator that will give context to your linear backlog, give it structure. It will highlight waste and gaps and I’ve found it to be critical for prioritisation. Each iteration may change the course of the product story and you can adjust you map accordingly.

    The relevenace of upcoming requirements are revealed as the iterations are progressed and thus the fedility of the detail for the requirements increases the more likely its going to planned into an iteration

    You can achieve the balance between ‘just in time’ and creating waste. As we know from bitter experience the waste we create when we get to far ahead of ourselves. By getting the holistic view of the product or project we keep lean and deliver value.

  13. Thanks for the compliment, Jake! I’m glad I wrote this article just to enjoy the conversation we are having here :-).

    Yes, in my example it was the luck of the draw, but… of course I used my analytical skills to ask myself, “which of these future requirements would benefit most from my starting early and spending time chasing information and developing a good understanding of the business problem and potential solutions?”. That is the key thing in my opinion. Yes, some of the items in the backlog would be OK with a JIT approach, with some even being easily put together in a couple of days, so no point in focusing on those first.

    But if I had finished with the more complex requirements, and still had time on my hands, my inventory of requirements would continue to grow (in parallel with scheduling some time for knowledge building in relevant areas, and other career development activities during the down time, of course). I guess I just like to accumulate a requirements inventory, heh.

  14. @Adriana So you just choose “from the stack” at random an hit pay dirt!? Well I want you on my next project!

    I think the great thing is that you had time to breath… and think… and the ability to actually “be done” and grab sometime else!

    To state the obvious, since “stuff” happens fast, being stuck on a 2 year project and unable to react does not help you succeed – doing the other work as JIT allowed you the option to choose something else!

    That is another blog post I guess!! 🙂

    Again – great topic!

  15. Everyone: keep your comments coming! I’m certainly enjoying the conversation.

    Two quick comments, as I have to go:

    @Andrea: “She describes it as a stroke of luck, where as trying this method might make it a more explicit group prioritization process based on rough cut of risk of delay (visible to everyone who walks by).”

    See, I don’t describe as luck, but rather as trying to be prepared as best as I can. The “lucky” part is that I ended up working on something that turned out to be needed much sooner than expected. Something else could have become the highest priority overnight, and we’d have to struggle with very little time to produce quality requirements before development started. The “last responsible time” here, is simply unknown, as things can change pretty quickly in a big organization.

    @Jake:”@April is right on – the team should be grooming the backlog (an iteration or so ahead generally speaking) and that does involve working ahead. I am unaware of anyone out there who does not recommend working ahead. Is there?”

    I’m not sure I’m getting my point across; what I mean is stuff happens that may change your backlog pretty quickly (or is it just me it happens to? I had this problem in many Fortune 500 companies I worked for).

    Of course we should always prioritize work based on what we know today, working ahead one or two iterations to have requirements ready on time. However, if after finishing the work on what is coming next I have the bandwidth to look further ahead, I choose to produce requirements in “non-JIT” manner. That’s just what has been working well for me.

  16. @Adriana – nice topic! More time needs to be spent on how lean concepts should be applied to business analysis.

    The first thing to remind everyone is the agile ext. of the BABOK is a DRAFT and you can comment on it through the end of February! Clearly they should take the word “g#!%!#hering” out of there! 🙂

    @April is right on – the team should be grooming the backlog (an iteration or so ahead generally speaking) and that does involve working ahead. I am unaware of anyone out there who does not recommend working ahead. Is there?

    @Andrea – great points on kanban and I agree with your assessment of just in time of course.

    From the example above, it almost seems like there was the ability to take on additional WIP and so that is what they did…

    Just in Time (JIT) does not mean the last possible moment. It is really the last responsible moment.

    The age old question “when do you know the most about a project?” (when it is done) – comes to mind. Doing too much analysis too early leads to wasted efforts on items that get removed, changed, or replaced…

    The real challenge is finding out what JIT means for your teams, projects and organization! If you want to know what the best practice is on this one, the best practice is to continuously improve.

  17. Andrea Chiou says

    There are no pat answers to anything. I fully understand what @adriana is saying.

    One thing I learned that was useful at the Kanban training I recently went to is that requirements backlogs or story backlogs (whatever you call them) can use a fairly simple mechanism to visualize their risk of delay. This is low cost visualization using stickies on a Kanban board. This then helps you/your BA team prioritize which ones you work on. Perhaps Just-In-Time doesn’t mean you DO something right before it is needed compromising its quality. It means you prioritize what you do based on its need in the time ahead, which is what Adriana describes doing. She describes it as a stroke of luck, where as trying this method might make it a more explicit group prioritization process based on rough cut of risk of delay (visible to everyone who walks by).

    Using these simple visualilzations helps everyone see which things should be worked first. The whole idea is to prevent work on something, that due to changes in business, becomes obsolete and unneeded.

    I am not preaching any methodology at all, but I have found reading about and learning Kanban very useful, though I have not used it on any project yet.

    It was interesting to read David Alexander’s tweets at the OOP2012 conference in Munich this week in which he said: “I’m noticing a focus on requirements Engineering at #oop2012 interesting as I’ve been hearing a lot that ability to define requirements is a major impediment to process improvement and agility. The de-emphasis of structured requiremetns analysis methods on the last decade appears to be creating problems”. Well, thank goodness we are all promoting good BA work, and trying to bridge-the-gap with the agile community. David Anderson, if you don’t know, wrote the Kanban book and pioneered its adaptation/use for software development at Microsoft in 2005 or so.

    If anyone is interested, I can cut out the few slides from that training that pertain to visualizing ‘cost-of-delay’ and mail them.

  18. April McClellan says

    Each role (Architect, BA, UX Designer, Developer, Tester..) on a software development project has their own life-cycle, so in practice, “just-in-time” shows up differently for each role based on the needs of the particular stakeholder. For example, I have found that the BA MUST stay at least one iteration ahead of the dev team in order to have enough time to elicit, analyze, define, communicate and get approval for the next set of requirements to be built. If you don’t have these ready to go when the dev team has delivered the last iteration, your backlog becomes a logjam with many idle hands. The BA has to look even further ahead for the Architect and the UX designer who always need the big picture, or else you risk building a hodge-podge, unusable product requiring loads of rework in every iteration. Now, if you plan for rework as part of your project and get the sponsors buy-in on duration/cost etc. then some teams will accept the re-work as a natural part of the “creative process”. Speaking of the creative process, this is one human process that agile/lean manufacturing process paradigms don’t seem to consider (i’m no expert on all the different paradigms so please enlighten me if there are some that really incorporate the ‘human factor’). It takes time for each individual human brain to ingest, process, understand and ACCEPT the information that is being communicated to them. This is before they even decide HOW to approach the design for what they have just understood. Software development is an iterative, creative process and each individual designs their solution differently even if the output and results are the same. Even with the use of centralized re-usable functionality in code libraries, you will still get individual flavours in putting the pieces together.

    • Kimber Miller says

      TRUE statement: “…If you don’t have these ready to go when the dev team has delivered the last iteration, your backlog becomes a logjam with many idle hands. …”

      As my corporation begins to explore adopting Agile at scale, this is one idea that my BA team is working with. Thank you, April, for a concise statement!

  19. @Craig: I’m definitely not sick of hearing you talk about requirements as inventory :-). I actually need to read your work about it. Thanks for the links, I will definitely check them out.

    @Andrea: “Kanban for software, as described and trained by David Anderson, does not proscribe specific tasks to be not done early, if there is value.” I wonder how this conditional “if there is value” works though. What doesn’t have value if I have the time available to start now to investigate some requirements that may not be needed until later?

    Let me explain what I mean using an example that happened to me very recently. As a BA, I have periods in which I’m overwhelmed with work, trying to figure out how I’ll be able to attend all the important requirements sessions and meetings in my calendar. In other times, things are much calmer. Decisions are being made about the scope of the next release, developers are working hard at building the solution, and I’m only needed for a couple of hours a day to answer questions or help with design. In one of these periods, I took a look at the backlog we had, and found something I could start working on: automation of business rules. The system I was working on didn’t prevent the users from applying some settings that should not be used together because they violated business rules. Manual controls were being used to ensure compliance with the existing rules, and the idea was to automate them, either preventing the use of certain combinations of settings, or displaying an error message to allow the user fix a mistake before submitting a transaction.

    In theory, that particular feature was not going to be part of the next release, but I wanted to allow me time to fully investigate the rules (some of which weren’t documented, and required talking to people from different locations around the world). So, I was prepared to create a specification that I would keep in my drawer until the time came to use it. Turns out that the business rules implementation became one of the top priorities for the next release, and there was barely one week available to produce and present the requirements to a vendor that would be responsible for developing them so the project timeline was maintained.

    It was pure luck that I had already done 80% of the homework, because otherwise we wouldn’t have had time to prepare solid requirements to deliver to the vendor, which in turn would produce a poor implementation of the business rules. So, yes, I was extremely happy to have my “requirements inventory” available (which includes other requirements that I have stored in various levels of completion as well). For me, starting early means I’m better prepared to “embrace change”, giving me an opportunity to perform the necessary analytical work, rather than having rush to produce requirements that may lack in quality because of tight deadlines caused by sudden changes in business priorities.

  20. Andrea Chiou says

    This sounds mostly reasonable, except for this: “Proponents of the practice of “reducing work in progress” will disagree with my approach of anticipating the creation of use cases, business logic, acceptance criteria, and any other requirements-related models I’m able to produce as early as possible in preparation for future iterations in my projects” Kanban for software, as described and trained by David Anderson, does not proscribe specific tasks to be not done early, if there is value. In fact, it is up to the team/org. to define/use its own process model and the apply empirical evidence to analyze where improvements can be made (adapt for fitness in the particular situation). Your analysis tasks can be seen as an upstream from the Development team process and you may or may not ‘limit’ your work in process for that upstream work. In your situation, your work may not be wasted – for others it might, but no one in the Kanban community would say your level of analysis cannot be done early if the business needs it.

  21. Good food for thought here Adriana.

    People must be sick of hearing me talk about requirements as inventory and a requirements half-life.

    By introducing these ideas I seek to shift the way analysts think and talk about requirements specs. Consider the cost as well as the benefit of moving too far ahead of the rest of the project team.

    The degree to which we work ahead of the team is situational and needs to be judged by the team on the project.

    Additionally our community needs to encourage each other to experiment with other modes of thinking and practice to help build diversity and a more situational specific approach to complex problems.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.