Product Owner’s Bag of Tricks
You don't have to do any of these things, but they might make for a good, productive time.
Create “Wedding Stories”
In Scrumland, we populate our product backlogs with something called "user stories." User stories are a particular way of framing the work to be done—rather than detailing the specific tasks, user stories focus on what you want to get out of the project.
In Wedding land, we call these Wedding Stories. If you simply articulate the value you're looking for, rather than getting hung up on the specifics, you just might find that your wedding planning process becomes more creative, experimental, improvisational, and fun. You may also find that you react better to setbacks and are easily able to change the plan when needed.
Here are some examples of Wedding Stories:
The ceremony will be a beautiful reflection of our commitment to each other
The dance party will be joyful; the music will reflect our family roots and traditions
Guests will actually remember the food at the wedding for years to come
Everyone will feel refreshed and energized the next day, not drained or let down
See how all of those Stories imply a bunch of tasks (e.g. write vows, create a playlist or recruit someone else to handle the music, book some tastings with local caterers, make transportation easy), but don't actually spell them out? That's the secret to writing great Wedding Stories—you articulate the ultimate value you're looking for, but allow for flexibility in terms of how you get there. To represent this, you could write your Wedding Stories in permanent marker, then capture all of the particular tasks under them in pencil, ready to be edited as fresh inspiration strikes.
Add acceptance criteria to your Wedding Stories
Acceptance criteria are a fancy way of saying "what needs to happen to be successful." Acceptance criteria are different from telling a team member how to get the work done. By setting up conditions of satisfaction, you're giving them the freedom to execute the project however they'd like, while ensuring that you'll be happy with the result.
Common acceptance criteria for Wedding Stories include:
budget considerations (e.g. “The unity ceremony materials should cost <$30”)
people considerations (“Since our aunt is helping to foot the caterer’s bill, she should get to go to the tastings” or “50% of the food must be vegetarian”)
venue constraints (e.g. “No open flames” or “No glitter” or “Needs to address the fact that there’s no parking lot nearby”)
aesthetic preferences (e.g. “No pink decorations” or “No jazz music”)
deadlines and dependencies (e.g. “The guest list must be finalized by the beginning of February so that we can send out the invitations with plenty of time”)
A note on the painful art of prioritization
Determining which tasks are essential and which are just "nice to have" can be one of the most challenging aspects of wedding planning, but if you can do it, you'll save yourself a lot of stress. Wedding Stories, including acceptance criteria, can help. You can also use the "CAKE" method of labeling each task with one of these letters:
C: Can’t live without it (non-negotiable)
A: Almost certainly need it (unless there are extenuating circumstances, this task should get done)
K: Know we might not have it (if there’s extra time, these tasks would be great to complete)
E: Extraneous (tasks never start out here, but sometimes they end up here as circumstances change)
Scrum Master’s Bag of Tricks
Estimating and Timeboxing
If your wedding planning crew finds it isn't consistently completing all of the work committed to at the beginning of the sprint, the Scrum Master might suggest including estimations as part of the Planning Meeting.
There are two ways to do estimations:
Time: Team Members can estimate in person hours (e.g. “If the two of us work on that together for three hours over the next week, I think we’d get it done, so let’s estimate six hours total”). Time estimates tend to get less accurate as the complexity of the project increases.
“Story points”: Story points aren’t directly related to a number of hours. Instead, they represent relative effort. So, you might arbitrarily decide that a typical task such as “Address, stamp, and mail invitations” is worth 1 story point. Other tasks would be assigned story points relative to that task. If you think that setting up a website is twice as much effort as sending invitations, you’d assign it 2 story points. On the other hand, if you think that making the playlist is half as difficult as sending the invitations, you’d assign it ½ of a story point.
Story points are less precise than time estimates, which can be good, because time estimates are often very wrong. What can we say? Humans are just bad at predicting how long something will take!
Assigning a time or story point estimate to each task allows you to easily swap out one task for another task of comparable "size." You can track the accuracy of your estimates over time, and learn how much you are able to accomplish per sprint. For example, you might say, "We had estimated that we'd do 20 hours worth of tasks this sprint, but we ended up spending 30 hours and not finishing everything. We under-estimated by about 50%. Let's keep that in mind when we estimate next."
Timeboxing is a great alternative to estimating, if you feel you don't have enough information to make an accurate estimate for a particular project. Instead of saying, "We estimate this will take two weeks," you can simply say, "We're going to timebox this at three days. After three days, we're going to check in to see how it's going. At that point, we'll have more information, and we can either make a proper estimate, or perhaps re-prioritize it." Timeboxing is great for tasks with any level of complexity.
Agree upon a “Definition of Done”
In any collaborative project, people might have different ideas of what it means for something to be "done." Acceptance criteria are created on a per-task basis, but Scrum Masters may want to help wedding planning teams come up with an overarching "Done" standard for all tasks.
Your Definition of Done might include:
Contract must be signed
Must be added to the day-of timeline
Someone has been assigned responsibility for it during the wedding
Must be paid for
Changing a sprint
One of the best things about Scrum is that it allows you to respond to changing circumstances. By frequently checking in about how things are going, whether the backlog is in the right order, and whether your acceptance tests are being met, you have ample opportunity to intentionally change the plan. Don't be afraid to abort a sprint and start over with a new Planning Meeting. There's no need to keep your head in the sand if something's not working.