Continued from Part 1
October 6, 2022
This app has gotten very complicated over the past few months. We have gotten really good and taking some basic requirements from the SME and detailing them over a few calls to make sure we have handled every element of the story. I find it frustrating sometimes to have to do so much hand-holding when it comes to requirements so I’m going to talk to the PO and SME to see if they can give us better requirements in the future. Every time we sit down, it feels like we increase the scope by 150%…
October 7, 2022
I was going to talk about requirements this morning with the SME but they ended up doing it for me. They were looking at some of the past items we spent hours working through and want to change the way it works now that they have seen it running in the app. We built exactly what we had discussed but the team doesn’t seem to have understood the requirement documents. We had a long conversation about how we can draft up more detailed requirements, the SME is going to spend a lot more time on the details going into the next sprint.
October 8, 2022
We are coming up on our original target date for pushing to production, but the PO doesn’t want to do so until we have some more recent features built and tested. We had planned on starting the push to production before the end of the year since we are going away for the holidays but I don’t think that’s going to happen now with these new requirements.
December 13, 2022
New week, nothing much else to say. The client still wants us to push to production but has some features they are trying to get into that push. They just aren’t even finished yet let alone tested.
December 17, 2022
I thought we were finished with a very complex feature where we built a custom matrix of nested list views but now there has been a last-minute ask to add in a 5th layer right in the middle of everything else. This is going to be extremely difficult with all the custom styling we already implemented, as well as all the data source microflows feeding each layer.
December 24, 2022
We didn’t end up finishing the prod push before the holiday break, now I’m getting text messages from the client on Christmas Eve…
January 8, 2023
Decided to skip pushing to production all together, SOW #2 has been signed and the project has been extended for another 3 months.
Let’s stop reading for now, time to analyze!
For this set of entries, I’m going to talk about all of them as a whole because there are a few core ideas here that need to be talked about. We see in the October entries that the project is starting to slip out of everyone’s hands. The stories are obviously not detailed enough from a requirements level and neither the development team nor the client SMEs are doing a good job of managing expectations.
It feels like we increase the scope by 150%…
If it feels like scope creep, bloat, moving targets, whatever you want to call it… it’s time to stop and re-evaluate all of our goals here. On any project, one of the most important parts of planning a sprint is setting your sprint goals. The thing is, if you are setting sprint goals as something like “The goal for sprint 7 is to deliver the inspection matrix and the fillable PDF”, you are always going to fail to deliver. But why?
You will fail because a sprint goal should not be a set feature. Instead, it should be to add some amount of value to the project. Example: “In sprint 7 we want to increase user’s visibility of inspections on the job overview so they can more quickly see the overall progress of the project”. Do you see the difference here? A sprint goal is not a promise for something specific, but instead a guideline for where the efforts of each sprint will be focused. Suppose a sprint goal above were to be set up beforehand and the client came to you 4 days into this sprint asking, “Hey we need to make sure the fillable PDFs are ready before the end of this sprint”. In that case, we have a very clear way to let them know this needs to wait until the next sprint planning because it’s not relevant to the current sprint goal. Besides the fact that it wasn’t part of the planning in the first place.
The client still wants us to push to production but has some features they are adamantly trying to get into that push.
This scenario is all too common, and something I think every developer runs into over and over in their career. A client understandably wants to see their application progress as quickly as possible, and a first push to production needs to be a culmination of all the sprint goals up to that point. However, what ends up happening is the ideal first push to production approaching creates this sort of shift in focus during the development cycle.
The client may notice a decrease in velocity in the weeks leading up to a production push because the dev team is shifting some efforts to data migration / documentation / environment configuration. What will happen here is the client will want the same level of feature progress with a production push squeezed in between, and this creates a moving goalpost for that production push because a feature developed a sprint before a production push should never be allowed in that push. You need to have a full UAT cycle for these new features before they can be considered for a production environment.
The takeaway here is to plan ahead for your sprint goals, but also for WHEN TO DELIVER THE VALUE! Building sprint goals around value is great, but only if that value actually becomes usable for the client. A successful sprint goal means nothing if it doesn’t become a reality for the client and their end users. Plan to realize the added value in regular increments, the more often… the better!
I’m getting text messages from the client on Christmas Eve...
This is for everyone, set some boundaries! It’s completely acceptable for you to set up specific dates and times when you will be available for your clients and not be available outside of those hours. Sure, you want to deliver the best customer service and professionalism to your clients, but you absolutely can not sacrifice your well-being outside of working hours to satisfy a client who is budgeted for a set number of hours. If you want to have a working weekend relationship with the client, this needs to be discussed beforehand and a structure needs to be in place for weekend or after-hours contact methods and billing. Do not spend your time and energy on something that isn’t logged in the project budget.
This set of entries touched on some critical parts of a project but only scratched the surface. Send me an email if you have any questions or want to go into more detail about these ideas.
This post was originally published on medium.com and can be viewed, here.
