Published on Jan 28, 2020 by Eric Lentz
Today we want to discuss how to keep an application development project within scope and budget, but before we do that, we need some background on some elements of project management. Software development projects have many commonalities with other types of projects. Bridge building projects certainly have concerns that would not be present in software development projects, but I would imagine there to be considerable overlap. Regardless of discipline, there are standard project management concerns like the following:
There may be many other things to consider, and it depends a lot on the project, but those are common items at a very high level. Many people feel that project planning consists of a gantt chart. Please acknowledge that a gantt chart represents only the project schedule and is far from being considered the full scope of planning.
In the above list, we haven’t even addressed the various phases of a project and what should be done at each phase and how one recognizes and acknowledges moving through the various phases. Phases, in this context, does not mean the various milestones towards the final product. In this context, I’m talking about things like initiating the project, planning the project, executing on the project plan, monitoring the project and then completing the project. Each of these phases may occur within a milestone or sprint or what would classically be called a phase 1 or phase 2 of a project.
For software development projects, there are some other items that require extra consideration as compared to other types of projects in other disciplines. Some of those include:
As with the previous list, this is also at a high level, but covers some common considerations.
There’s so much to consider when properly running a project, some of which were just highlighted. Failing in any one of these areas can be anywhere from an inconvenience to a catastrophic failure. For smaller projects, an expert can quickly recognize the risks and follow standard procedures for executing a project with little concern of failure and without the need for many of the aforementioned formalities. Whether the project is big or small, it is critical for the specification to be well articulated. That responsibility lies squarely in the hands of the service provider, not the project sponsor. A service provider needs to help its clients communicate what needs to be built into “Goldilocks” specifications, which aren’t too little or too much.
A project is so much more than individual specifications, but if you get the specifications wrong, the rest becomes rather immaterial. The specifications, whether teased out over project sprints as in an agile project management approach, or planned fully upfront using a waterfall project management approach, have a huge impact on project scope. Properly understanding project scope (or misunderstanding it) causes impacts in most of the other areas or a project. Misunderstanding the complexity of a feature, or set of features, can be the difference between a successful project and one where everyone gets stressed out and where unexpected compromises mar the final result.
Specifications and estimates go hand-in-hand. Just like the specification, the estimate is also super important. It is unlikely for any project with any long duration, regardless of management approach, to start without some kind of understanding of the anticipated cost of development at the end of some major milestone, which might encompass many sprints or some long duration of development. The specifications and estimate work together to make it possible to develop an understanding of costs. Without solid specifications, solid estimates are impossible and project success is also highly unlikely.
If specifications are so crucial to project success, then how do we ensure that we get specifications that are accurate?
User stories are a great way of ensuring that a project has the correct specifications. User stories may not be the only way of getting the correct specifications, and only having a user story is insufficient, but it is the best vehicle for getting everyone on the same page. A user story depicts some discrete feature that will be present in an application. It presents the story from the aspect of a user, in non-technical terms. There can be technical elements, but a story is best written when it presents a business outcome that one wants to achieve within the software.
The format of a user story is important, but there can be variations so long as there are 3 key aspects that are fully understood:
To make it easy, a template exists that one can follow:
As a ________, I want to be able to _______________________, so that _______________
Here’s an example:
As a sales clerk, I want to be able to change the shipping date on an order that has gone even as far as being staged for shipment, so that the system can handle notifying whatever the appropriate department is without me trying to figure it out by checking the current status of the order and then trying to contact the correct person in that department.
Notice the specificity of that story. Firstly, we can see that the primary or sole user of this feature is the sales clerk. That’s the role. Then, you’ll see that there’s a description of what the user wants to be able to do - change the shipping date on an order that isn’t already shipped. It doesn’t specifically say the order hasn’t been shipped, but one can deduce that from the comment about changing it up to and including being staged, which can happen just before being shipped.
Finally, there’s a rather lengthy description of the justification. In this case, the justification highlights the workload that will be alleviated with the additional feature. One can easily see from this story that there will be considerable thought required in determining how notifications will be forwarded to the correct people and in some kind of timely way, such that, for example, a staged order doesn’t get shipped.
In some cases, it might be useful to include another part of the user story. Specifying the “when” of a user story can sometimes be useful in calling out more specifically what the feature is and how it will be used. Here is an example of how this might be used.
When an order is past due by a configurable number of days, as a sales clerk, I would like to receive a notification that the order is past due, so that, in keeping with our commitment to customer satisfaction by maintaining high levels of communication, I will know to call the customer and explain why the order has not yet been shipped and determine if the customer would like to continue with the order
Notice how the example story doesn’t read like this:
Don’t do this
As a sales clerk, I want to be able to change a sales order to reflect changes in the shipping date, number of items ordered, create backorders, set up a delivery schedule, and cancel orders, so that the order can be changed when a customer calls in.
There are a few problems here. The worst offense is that there are way too many things addressed within this one story. Cleverly, this would be considered an epic. If a story is what you want, then an epic, consisting of many stories, is definitely what you don’t want. If one can break out multiple stories from a single proposed story, then that story is an epic and should be broken down into multiple smaller stories.
As we saw initially, just the shipment date change can be significant in terms of the design time required to going into figuring out how people get notified. Creating a backorder, which also requires coordination, or adding to the number of items ordered or really any of those other discrete features, could be rather complex on their own.
The other problem with this story is the justification. The “what” statement said the sales clerk wanted to “change a sales order”, so a justification of, “so that the order can be changed” isn’t very helpful. A better justification would be, something like, “So that sales order changes can provide the desired impacts within the other departments of the company so that the correct thing happens for each change.” As a designer and software developer, there would be many questions in fleshing out what the “correct thing” are for each of the functions specified, but at least now it would be known that such exploration is necessary.
Now we have the story, it is now time for a designer or developer to flesh out the technical details that each story necessitates. This will be a list of programming steps and sub-features needed to create the story. Some call these “conditions of satisfaction” as these smaller details demonstrate what is required in order for the user story to satisfy the particular use case.
Armed with this information, the designer or developer can now estimate each of the conditions of satisfaction and roll those up in order to get a complete story estimate. Some project teams use a point system. Some teams will use actual hours, but whatever the approach, this gives the project manager the scope of each story. Knowing the scope of each story, the scope and estimate of the entire application can now be known. One also needs to consider various project related costs, but for the sake of this discussion, we’ll assume those are handled.
So how does the user story help one stay in scope and on budget? As we’ve said, the scope largely comes out of the user stories, and the work done on fleshing out the technical requirements of the user story. Simply understanding the scope, staying within it and staying within budget isn’t enough for project success, but it represents one of the largest contributory elements. As Yogi Berra famously said, “You’ve got to be very careful if you don’t know where you are going, because you might not get there.”
As mentioned before, there are other elements of a project that must be managed as well. We’ll consider some of those next and see how user stories impact each of these areas of the project. In doing so, we can see how crucial the user story is to project success.
Each story has an estimate, and those estimates get rolled up into functional areas of the application, or some other grouping as decided by the project manager. How well development is performing against the estimates is a critical measure. Some teams will measure velocity, such that, as the project proceeds, there becomes a natural cadence of story completion. This can be simplified by using the point system. Doing so, a team can measure the number of points a team can complete within some time period, such as every week or every two weeks.
Being off on a specific story is to be expected. Some stories will be completed more rapidly than planned and others will take longer. As a whole, we’re looking for an equilibrium around the project budget for a given time period or within a given functional area.
When one accurately assesses the velocity of a team, then one can forecast a schedule. One can also measure actual schedule performance by comparing the estimate to the actual completion time. As such, there’s a pretty tight correlation between estimate performance and schedule performance, and it is all rolled up from the story.
Since each story is a discrete unit of work, it is quite easy to ask questions, report status, request feedback, request that testing gets completed, request a meeting and many other things, with the user story as the focal element. Having a unique identifier, per user story, also makes it very easy to establish context without using many words. One can say something like, “Regarding s76, did you want the user to…?” A lot of time, accumulated over the course of a project, can be wasted in communicating context and using a unique story identifier can help eliminate this waste.
With all the conditions of satisfaction all fleshed out, it is easy to know what needs to be tested. A tester can examine the condition of the application by examining all the conditions of satisfaction and determining if all such conditions of satisfaction are present. By definition, we would expect satisfaction if they are.
When initially reviewing the stories, a technical person can identify areas where technology is lacking with regard to the completion of a particular story. Other risks might include knowledge of gaps in technical capabilities of a technical staff in a given area. That can represent budget risk and schedule risk, but can also create a potential impasse. As such, a useful technique is to identify these risks at the start of the project and front load those user stories to be completed first, if that’s at all possible. In that way, the project team can identify early on if additional funding might be a requirement, and they can also decide to convene a meeting to discuss a go/no-go decision.
Sometimes, front loading a particular feature isn’t practical because other features present as a dependency to the risky feature. For example, a machine learning project might require 20 years of information, and the accumulation of that information is a requirement in order to determine the usefulness of the model. Such accumulation might require dozens of hours of programming work. Suppose the project team doesn’t have much experience with machine learning. One might opt for developing a proof of concept. A proof of concept is a small, standalone application, that attempts to create enough of the desired features as to determine that it is possible to achieve the desired goals.
The creation of a proof of concept might require additional budget, but is a great way to mitigate some risk which might result in a great financial loss if it is determined much later that something could not be developed cost effectively. Often times, the proof of concept also allows the developer to create some code that can be reused when building out the final user story. Also, it’s common for a developer to get better with each iteration, so the development that ends up in the final product ends up being much better than would have been if the developer only programmed for the user story once. You’ve no doubt heard someone say, or you’ve said it yourself, “If I had it to do over again, I’d…” This happens for developers too.
With the user story as the centerpiece of project deliverables, change management becomes quite easy to perform. Changing the project includes changing the individual stories, as well as adding or subtracting stories. Stories that are changed, require the conditions of satisfaction to be updated as well. One simply updates or accumulates the estimates for the new, updated and deleted user stories, and a cost delta thereby gets created.
A feedback loop between the users, project sponsors and development team is quite important to have. Stories permit learning to go on within the team and for this learning to be applied to the project. The structural format of a user story lends itself quite well to inspiring inquiry and subsequent communication among the project team. The justification section, in particular, is good for this. It helps those, who would otherwise not know, understand why a feature will be used and very often cause one to question a rationale, not to be difficult, but to better understand how such a justification can and should be had within the application.
Using this learning allows for improvements in the development process for future work on the project. Rather than catching bugs later during testing, it is better to keep the bugs from getting into the product in the first place. The story helps increase developer understanding so particular use cases find their way into their work product. The user story then gets considered during testing by a tester, and if the story isn’t recognized in the application, then it is easy to identify and communicate to the development team. Feedback is thereby streamlined by using user stories.
‘ilities are non-functional requirements that need to be present within an application. Localizability, for example, would refer to an application’s ability to run multiple languages. We would generally refer to this as internationalization, but in keeping with the ‘ilities concept, most words ending in ‘ility, one might say localizability. Knowing this at the beginning of an application build is quite important. Adding it later, generally speaking, will be more costly than adding it from the beginning. Most ‘ilities are overarching non-functional features that need to be considered throughout the application build.
User stories may be of help here as well? A story might include that a particular role desires to enter a second language into the application or within a certain area of the application. In most cases, however, one would simply specify the desired ‘ility and then either make sure it is part of a standard addendum to the conditions of satisfaction, or ensure that such ‘ility feature gets added to each of the conditions of satisfaction of the user stories. A final alternate approach might be managing it within the testing portion of the project, ensuring that the application gets tested to ensure that another language displays correctly when selected.
Regardless of where ‘ilities are represented, it is quite important to ensure that they are presented as early on in the project as possible and tested, as needed. A client once came to me asking for an application and nearly all the first part of the initial discussion was about an ‘ility, namely scalability. The client knew that the application must provide a certain performance goal, for long-running processes, and that it must achieve this for multiple customers simultaneously. This highlighted the need of utilizing cloud computing to horizontally scale the application and isolate processing, per customer. Learning this late in the project would mean that the application would be built unable to perform in the way that was needed. Needless to say, that would have been disastrous.
Running a project can be difficult, but many of the complexities of an application development project can be avoided by making good use of user stories. User stories permit the project team to fully understand the requirements of a project ahead of time. This is the main challenge of an application development project: understanding scope. A firm handle on scope means having a solid chance of creating a good estimate. A good estimate leads to a good schedule, which makes staffing decisions easier and allows everyone to plan the arrival of that shining new application. In the end, with user stories, your project gets completed on time and on budget with the least amount of stress possible.
Is this what you want? It’s up to you. I’m only asking you to consider what is true.
We enhance your Internal Products that you can use to produce predictable and scalable results for your company, allowing for growth while requiring less management effort.