As you grow into your career, you start to understand that a healthy development process is more than just good code. It takes predictability, the ability to easily pivot when surprises occur, proper time estimations, and a few other key aspects. How do you achieve this by chance you may ask? The answer is easy, a solid process.
Having a process down that is not only reliable but flexible as well, is the key in the software development cycle. This allows for easy tracking and a more relaxed way of handling the naturally expected random blow-ups that come with software development. Especially true in large enterprises.
So, how do you accomplish this? Let’s take a quick dive!
Setting A Starting and Ending Date
It’s fair to assume that most engineering teams are following some form of agile/scrum today with confidence. This is a great approach because it allows for the project to naturally flow throughout its duration, without the need for too much concern if some things take longer than others. This is great, but there is one somewhat misunderstood issue of how to set proper guard rails to ensure projects actually get done.
That’s where start/end dates come into play! Having a well thought about starting and ending dates, and sticking o them, will keep everything in proper perspective. Shifting dates, or even the thought of doing so just because, reduces productivity and removes a healthy sense of urgency needed for things to get done on time. Think about it, if someone knows then can just continuously move the goal post back what motivation would they have to even try to score or defend it. None!
Having concrete starting and ending dates are only the first step. These dates are used to determine progress and get a sense of where things are during the project duration. There is a gap that just these two dates alone can’t resolve though. You can easily get a feel for how the project is doing in terms of total completion, but not really a good read of how much work is actually done.
This is what velocity milestones do. Being able to group sets of related tasks, even so into a feature, allows a deeper dive than just a percentage of work done. It gives a read into where major pieces are in the grand scheme of the project, time estimates of how much time/effort different tasks will take in between each other, and so much more.
This is something I can not stress enough. Strategic planning is a critical aspect of any project I engage in. There will always be some unknown or unexpected blow-ups, that will throw everything off track. No matter how simple, or difficult, this is the one immutable truth with software development projects.
That is why strategic padding is so great. Understanding where and how to properly pad tasks will save you from that. Simply adding a safeguard amount of story points or time can be a lifesaver for you down the stretch.
In short, these are three critical points that I look at when creating a project plan/roadmap. I know they seem simple, but in actual application, it takes years of practice to get it down to a science. Hopefully, you can take these into your own planning process and flourish!