Start with requirements

It’s always risky to rush into the first “obvious” solution without staying with the problem long enough. That’s why we have a certain process:

Requirements → Deliverables → Activities

Many plans start with activities or deliverables. Ideally, though, we want to start with requirements, then use the requirements to design the deliverables, and finally, see which activities are needed for building those deliverables.

This process is the same for predictive and adaptive projects. The difference is that most requirements are identified at the beginning of a predictive project, but must be identified gradually during an adaptive project.

So, what would you do if someone told you, in the middle of an IT development project, that they need to have a feature for the support staff to be able to log in as different users without having the passwords of those users?

What they’ve described is a deliverable, and you must ask questions to understand what the requirement is behind this deliverable. When you find the requirement, check to see whether there are other solutions for it, and which one would work best.

The traditional approach in adaptive projects, mainly created in XP (eXtreme Programming), is to describe what they want as a user story, or story for short. There are different ways of forming a story, and the modern way goes something like this:

As a member of support staff, I want to be able to log in as any user without having their password so that I can check what they see from their side and try to solve their problems (e.g., missing an order) instead of asking them lots of questions or expecting them to send screenshots.

This format contains a reason at the end that works like a requirement and encourages everyone to think about it. Besides that, it helps reinterpret the request; for instance, in the example above, we can see that they wouldn’t need to log in as high-privilege admin users (that would be a bad idea) and it’s best to make that clear right away.

Is this concern explicit enough in your methodology? If not, you may need to do something about it appropriate to the size and complexity of the project.