What techniques can identify missing requirements?



  • I am working in a Scrum team developing methods and tools for use inside our organization, although our skillset tends more towards statistics and data science than traditional software development.

    We have a general idea of the main requirements for the product we are currently developing and have already made progress on them, but we have a lingering feeling that we've missed something obvious. Are there any valuable techniques or frameworks for finding those gaps?

    The users/customers/stakeholders will be the primary source of this information, and Sprint Review is a crucial opportunity for achieving this. But are there some ways to run the Sprint Review to better elicit the information from them, or things we can do outside of Sprint Review as well?



  • I'm not entirely sure if that is still "project management", but what has helped me in my developer role is to actually take a day and do the work that my program is supposed to improve.

    This yields at least four good kinds of information:

    • Sometimes, users of the old program are so set in their ways, that they just want the same. Just better. While actually a completely different approach to the problem altogether might be better. You will never find that out by talking to users of the old program.

    • Sometimes, you as a programmer are frustrated by a step in their work process because you know it could be easily automated, while the users of the old program have just accepted it to a degree that they won't even mention it any more.

    • Sometimes, when they explain their work to you, you notice that changes in their process and work routine could easily eliminate programs or part of programs they are asking you to write. I once scrapped a full feature of organizing and filing and assigning tasks by just asking why they don't just switch steps in their process around so they don't need this whole coordination software. Turns out they never thought about it.

    • You get UX information. I once built a software that had a screen with two buttons, each of them as big as half the screen. It looked horrible. Like a four year old had accidentally clicked around in an UI builder. But it worked. For their purpose it was perfect. Because they were standing in a warehouse with thick gloves on and if they had a normal looking user interface, they would need to take the gloves off, click the tiny button, put the gloves back on and continue working. With the ridiculously huge buttons, they could move the mouse and hit them even with their thick gloves on and never needed to take them off. But that is not information you get when you sit around the requirements planning table with their foreman's boss who has not been on the floor a day in his life.

    Are there ways to ponder about the requirements in theory around a table? Probably. You can invent personas and play through all their tasks with your software, but it will still be a theoretical construct brought to you by people most likely one or more steps away from actually doing the work and using the program. The only way to actually get a grip on it is doing it yourself.

    So what can you do as a project manager? Well, resource planning is your job. Plan it so a few of your developers have the time to actually experience the thing they should improve.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2