So what's your priority?

In the fast paced world of software development, sooner or later you or someone on your team will find a situation where they are faced with multiple tasks, and competing priorities.   So what does a person do when an urgent list of changes to a software under development is received?   Then what do you do when the expected time to deliver these features appears to be something rather aggressive?

Let's take a step back for a second to discuss the requirement process.  Often requirements are not as detailed as necessary to begin to design or codify.   Sometimes requirements may be in a list form, they may be rather obvious, but more likely they are obscure, cryptic, or down right confusing.   Because of this, very often there is a necessary feedback loop between the team and the client just trying to make sure they understand the change, and the impact it may have on the system.

This back and forth, haggling over specifics, and gaining enough understanding to model the process necessary to be implemented can be very time consuming, and often the hardest part of the software process. Customers do not always have the computer knowledge to give sufficient feedback about what they write, and as a developer it is our jobs to not just verify that we are building the software correctly, but even more critical, we must validate that which are building actually meets the needs expressed in the requirements.

Often the understanding of a requirement will morph over time, but for simplicity's sake let's assume for a moment that the haggling over the requirements has already taken place.  So your team is called into a rushed meeting to discuss a list of changes.  The manager describes the ten items that need to be implemented, and expresses the hope that it can be done in a short amount of time.  For sake of argument lets say its a week.

Immediately the issue of time and priority may come to the forefront.  If there are ten changes to a system, ten changes that do not necessarily 'interact' with another or depend on another, then how do you prioritize them?  Depending upon what model your process is based upon the answer could vary.  It may be the Project Manager who sets these priorities, or in a more agile environment it could be the customer, or the person designated as the 'product owner' within the team.

So the team after a little debate comes to the decision, much as they might like to pick and choose which pieces to do in what order, they need one more layer of feedback about the requirements, what is the order of priority for these changes.  Given that the team is taking some measure of risk trying to rush these ten features into the system in a week's time, they believe that this risk would be easier to stomach if they could impose some logical order to implement the features, so that if the time should prove insufficient, they could at least be sure to have the  most critical features done and deployed.

So what do you think the response would be?  Hopefully you'll get a list of points itemized from one to ten giving a clear order of development and importance to the customer.  That would be the ideal, but what if the list comes back with six of the ten items listed as priority number one, and the other four as priority number two?  I posed this question on Twitter.

I received a few different responses two of the more interesting ones were from Stephan (@S_2K) "Everything is most important. " Morgan Ahlström (@Morgsterious)  replied with the understanding words "That noting is REALLY important."  These were very much my same sentiments when I pondered this question.  If someone cannot distinguish a hierarchy between two things, let alone ten things, how then can you know which items are of most importance and tackle those ares of the software first?  Even if you have multiple team members, it is only natural that some components may still have higher precedence.  


So what do you do when you have this sort of situation?  My hope would be that enough time would exist to push back for further definition of the structure of the requirements.  However, given that the customer might not be as eager to be asked the question a second time, or might not be as readily available, the team is then left to its own deductive skills to try and figure out the proper order to do them in.   This is where knowing a bit about potential dependencies within the requirements could lend aid into determining an order of construction. 


Nevertheless, it is still highly probable that there can be no clear prioritization gleamed from this answer.  With time being ever more tight then the team is left to its wits, and knowledge of prior conversations to try and 'best guess' the order they should tackle the changes.   In the end the team might complete all ten, or they might completely only a handful of the tasks.   In the later situation, the customer might then push back and ask why they completed one task but not another.  The team then can remember that it didn't get the accurate feedback it requested on prioritization, and could provide this as reasoning for the order they had chosen.


The customer might not like that sort of response, but sincerely in the absence of information, it becomes better to complete at least some of the work, even if you do not know how much, or what order it should be done in. This may not be an ideal solution, but it should be evident from this how important communication with the customer must be to ensure accurate building of the software and the timeliness and sequence of delivery.