With Thanksgiving behind us and the December Holiday fast approaching, it always gets me thinking about overeating. One more piece of pie won’t hurt me, or constantly grazing all the treats laid out even when I am not hungry. It doesn’t seem like a big deal until you are so stuffed you feel awful for a couple of hours, or even worse, you step on the scale in January, and you wonder where that 10 lbs came from.
Where are you going with this?
Thanks for the digestion tips, Chip, but how does this apply to the software project I am working on?
Just like having one more piece of pie, adding another feature or a string of changes to your project or sprint can cause you and your team a large amount of heartburn. Making choices like this in a vacuum, without considering the impact on other features or the team, doesn’t just hurt yourself. It impacts the entire team, the project, and your budget.
Suddenly everyone is sitting on the couch saying I don’t feel well.
Meal/Sprint planning
A well planned sprint is like a good meal plan to maintain or lose weight by a set timeline. Keeping your sprints on track and well thought out keeps you on pace to hit your release date.
Changing your sprints or adding items is like snacking when you shouldn’t be. You worked hard to plan your sprint/meal plan, but you couldn’t resist sneaking that one extra piece of pie in, and now your calorie budget is shot and the number on your scale isn’t looking good.
Suppose you start adding big unscheduled meals or even a few snacks, even if they are small. It’s going to cause problems for the team and the project schedule. Even small changes require time, thought, and effort. This all adds up in the end.
Before you add that feature to your project, think hard. You might think “I want it right now”, but it is often better to wait until the next proper sprint.
Put that cookie down, and think about it before you take a bite.
It’s just one cookie!
Anyone who’s been around fresh chocolate chip cookies knows this for a lie. One little cookie leads to another and another. Suddenly the whole cookie tray is gone, and your hands are covered in chocolate.
Not only will you pay for that later, you also set a precedent with the team that you can add items to the sprint anytime you want. Like that one cookie, it doesn’t feel like a big thing, but those little changes all add up. The team starts to lose faith in the sprint planning because they know it will change. They begin to lose track of project priorities because things are constantly moving. Before you know it, the team is missing dates, and more sprints are being added. The schedule moves out, and the budget goes up. This saps your momentum, and frustrates your team.
I like to call this dying by a 1000 little cuts. Most projects are not thrown off by one thing but by a bunch of little, unplanned, unscheduled little changes that all seemed reasonable and small at the time.
You are too strict
I’m not saying you can’t ever add features or change your sprints. However, if you are going to make a change, ensure you are doing it for the right reasons, not because you want to see a feature early. Sometimes you need to let the cake bake before you start working on the frosting. Be sure to check with your leads for the impact on the product, the team, the schedule, and the budget. Every change you make has its costs.
Before adding something, ask yourself: is this worth risking my timeline or budget right now? The answer is usually no.
Just gotta have it
Suppose you have to make a change or are asked to make a change. I strongly recommend you create an official change request form. A change request form spells out what the requested change is and what the impact is on the project.
- Are features being moved out or cut for this change?
- Are you going to need more resources?
- Do you have the right resources for this change?
- Are you changing the dates of the sprint because of this change?
- Are these changes going to impact the budget and the schedule?
Make sure the change request form is filled out with all the issues, dated, and signed by all the stakeholders. You want to make sure you have a record of all these changes. Going through the exercise of creating the change request form is helpful for two reasons.
- I have filled out many change request forms and presented them to the client. After seeing the impact on the project, the client often decides not to make the changes in the end or wait until a later sprint. This saves valuable time before the dev team gets engaged and starts burning time and money.
- Sometimes a stakeholder returns, having focused on something else for a while, and asks why the project is going long, or the cost went up. WIth change requests, everyone can review the decisions made and refresh their memories on the changes they wanted and agreed to. This prevents endless hours of finger pointing, or timeline reconstruction, which are not helpful to anyone.
Moderation
All projects have their ups and downs. As a product owner, you can control them. With some self-control and good decisions, you can still have that piece of pie and share the rest with the team.
Happy Holidays from the Modern Logic team
When you return from your long winter nap, you might realize you need some help. Modern Logic has a fantastic team that has been shipping consumer software on time and on budget for over a decade. We’ve a proven track record of helping companies ship products faster & better. If you think an agency might be the right approach for you or are curious to learn more, you can reach out to us at sales@modernlogic.io.
If you have thoughts or comments on this post, you can reach me personally at chip@modernlogic.io. I’d love to hear from you.