Published on Jan 28, 2020 by Eric Lentz
At Software Prophets, we’re primarily concerned about product development within software development projects. Bridge building projects certainly have concerns that one would not have for software development projects, but there will be considerable overlap. Regardless of discipline, there are standard project management concerns like some of the following:
There may be many other things to consider, and it depends a lot on the project, but those are some of the common items at a very high level. Many people feel that project planning consists of a gantt chart. At Software Prophets, we acknowledge that a gantt chart represents only the project schedule and is far from being considered 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, mean things like initiating the project, planning the project, executing on the project plan, monitoring the project and then completing the project.
For software development projects, there are some other items that require extra consideration.
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. Failing in any one of these areas can be anywhere from an inconvenience to a catastrophic failure. For smaller projects, a “Software Prophet” 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 that the specification 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. Misunderstanding the complexity of a feature, or set of features, can be the difference between a successful project and one where everyone is stressed out and where unexpected compromises mar the final result.
The estimate is also super important. Sure, if you’re using an agile project management philosophy, the individual sprints are boundaries around which one can recover, reassess and address future development scope and estimate, but it is unlikely that any project, with any long duration, will start without some kind of understanding of the anticipated cost of development at the end of some major milestone, which might encompass many sprints. That means that the specifications, scope, and estimate are the single most defining aspect of a project.
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 with 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 state that, but one can deduce that from the comment about changing it up to and including being staged, which is 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, a staged order doesn’t get shipped, for example.
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 couple of things wrong with this story. The worst offense is that there are way too many things being addressed within this one story. Cleverly, this would be considered an epic. 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” to have happen would be for each of the functions specified, but at least now it would be known that such exploration is necessary.
Now that 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 needed to be done 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 and some 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 of the entire application build can now be known.
So how does the user story help to keep a stay in scope and on budget? That’s simple. Accurate knowledge of a project’s scope is fundamental to being able to measure success of a project. Simply understanding the scope, staying within it and staying within budget isn’t enough for project success, but maintaining scope 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.”
It goes beyond just that though. Other elements that must be managed, as mentioned before, includes:
Depending upon the project, there may be others. This is not an exhaustive list. It is up to the professional to decide other factors that need considered and address as needed.
We will now examine how user stories impact each of these areas of the project.
Each story will have an estimate and those estimates are 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 project a forecast on 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 testing be 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 of 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 of the conditions of satisfaction and determining if all such conditions of satisfaction are present.
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 risk to budget and schedule, but can also create a potential impasse. As such, a useful technique is to identify these risk 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 required 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 many other features are required 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 required 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 of the 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 user story. Also, it is 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 is quite easily performed. Changing the project includes changing the individual stories, as well as adding or subtracting stories. If these stories are further categorized within a functional area of the application, which would be a very natural way of grouping, then it can be useful to first roll these changes into the functional areas in order to see the impacts to budget and schedule at that level. In this way, if there’s one functional area that is disproportionately affected, then one can decide if it makes sense for it to be so impacted.
If a functional area is disproportionately affected, then one may desire reviewing the user stories that make up that functional area looking more closely at the justification portions of the user stories and perhaps further working with the authors of the user stories, and the user roles, in order to determine if the justifications hold up to scrutiny. This may give justification to moving some user stories into a backlog or completely eliminating some of the user stories. One can argue that this should be done at the start of the project too.
A feedback loop between the users, project sponsors and development team is quite important to have. This permits learning to go on within the team and for this learning to be applied to the project, allowing improvements in the development process for future work. Rather than catching bugs later during testing, it is better to keep the bugs from getting into the product in the first place. Reviewing project work and communicating preferences in feature expression, early on, allows those preferences to be introduced into the application with all future development. This helps reduce costs by allowing preferences to be introduced before code is created, thus limiting the number of places that need to be revisited.
Again, the user story can be the centerpiece for this kind of activity. Testing and feedback can be done simultaneously. Testing isn’t just determining if there are bugs, it is also for the examination of all aspects of the operation of the application. This is time to provide feedback to the development team. An issue tracker is a very good way for helping the team to communicate. This allows issues to be responded to and tracked to ensure that the issue is completely addressed.
In review, ‘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 will, generally speaking, be more costly than adding it right 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 is added to each conditions of satisfaction section of the user story. A final alternate approach might be managing it within the testing portion of the project, ensuring that the application is tested to ensure that another language is displayed 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 the first part of the initial discussion was about an ‘ility, namely scalability. It was known that the application must provide a certain performance goal, for a long running process, and then 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 full understand the requirements of a project ahead of time. This is the main challenge in an application development project, understanding scope. A firm handle on scope means having a solid chance of creating a good estimate and 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, your project was completed on time and on budget with the least amount of stress possible.
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.