Micro Focus is now part of OpenText. Learn more >

You are here

You are here

3 prioritization techniques to beat software deadline stress

public://pictures/rouan.png
Rouan Wilsenach Software Engineer and Senior Technical Leader, Independent Consultant
 

Most software professionals I know have been faced with an unrealistic deadline at some point in their careers. The looming deadline is an all-too-common occurrence in the tech industry and a leading cause of both burnout and poor-quality software.

There are ways to avoid projects from being planned with poorly thought-out deadlines, but in an enterprise environment it's often too late, and promises have already been made. A deadline has been committed to without consulting the software development team, marketing has begun early, or contracts have been signed with external parties.

The ideal solution is to have technical involvement earlier in the planning process, but even without that there are things you can do to help make the best of a bad situation.

When faced with an unrealistic deadline, there’s a choice to be made. Something's got to give. Do you do all the things requested, but do a bad job because you're under pressure and there's not enough time to do them properly? No. The answer is prioritization and coming up with a picture of what "good enough" looks like.

Here are three simple prioritization techniques to help you beat that deadline and deliver useful features on time.

1. Find the must-haves and forget the rest

When time is limited, it's important to accept that you won't get everything done. The trick is to find the most important features and deliver those first. That way, when you inevitably don't get to everything, it's the less important features that won't get done.

I like to use the MoSCoW prioritization technique to sort the essential from the rest. Work with your stakeholders to sort tickets into four buckets: must have (absolutely essential for success), should have (we can make do without it in a pinch), could have (would extend the core functionality), and want (nice to have).

Most people designate the "W" in "MoSCoW" as "won't have," but I prefer the idea that functionality can still be desirable and will only be added much later.

The most important thing when doing a MoSCoW exercise is to take an active role in challenging your stakeholders' views on what’s important. I don’t think I've ever gone through the exercise without most features starting in the must-have bucket.

The trick is to persevere, to keep asking questions and suggesting alternatives until you've trimmed down the list of must-dos to the bare minimum. Because, let's be honest, that's all there's really time for.

2. Split those user stories 

Most teams these days have gotten used to the idea of splitting work into user stories. The trick many miss is that story splitting—breaking a user story into its smallest possible parts—can allow work to be prioritized in a more granular way. This helps unlock the true power of prioritization.

Imagine a user story like the following: "As a tax practitioner, I want to fill out my clients' financial information so I can obtain a calculation of their projected tax." We often add client-side validation to forms, because it provides faster feedback to users and ensures a better user experience. But does the tax practitioner really need client-side validation to obtain the calculation?

If you split out "As a tax practitioner, I want client-side validation on the financial information form, so that I can spot and correct my mistakes quickly" into its own user story, you can prioritize it on its own.

It's probably not as important as your must-haves, so splitting the story allows you to put less-important requirements aside in favor of the essentials. Focus on what you really need and leave all the other little bits for later.

Taking this approach not only prevents gold plating—adding unnecessary or frivolous features or requirements—but also allows for more learning. For example, you may know more about what kind of validation is most useful after a few months of running the system and gathering user feedback than you do when developing the system.

In addition, working in smaller batches is a core concept in agile for good reason—it actually helps you get things done faster!

3. Keep it lean

Odds are that, with a little effort (and a little pressure), you can imagine making do with much less than you thought initially. Keeping it lean is all about finding the most efficient ways of building a product. Do you really need separate edit and view pages (the R and U in CRUD), or can users just read the information from an edit form?

It's worth thinking about what functionality doesn't actually need to be integrated from the start. Is there anything you can do manually for a few weeks after launch?

For example, while your user base is still small, you could send notification emails manually. Set up your product owners with database access and a simple query, so they can find out what new events have happened in the system.

You might even be surprised what you learn with this approach. By looking at the data closely, your product owners may learn more about how the system is being used, and by sending emails themselves they may be able to build some personal relationships with users.

They say necessity is the mother of invention, so get a little creative.

Work smarter

With a tight deadline, something's got to give—but if you use the right prioritization techniques, it doesn't need to be your evenings or the quality of what you're building. Focus on what's important, be critical about what actually gets done, and be creative about the way that you solve problems.

In my experience, this approach leads to happier development teams, more satisfied users, and a more profitable venture overall.

Keep learning

Read more articles about: App Dev & TestingApp Dev