Phase 1: Close Out the Current Sprint (Steps 0–2)
- In Jira, create a new sprint with an incremented number and a generic description.
- On the current Jira sprint board, go through the Shipped tickets and Accept all the ones you can with screenshots showing the successful implementation.
- For tickets that aren't Accepted, document the gap and move them back to In Progress.
- For tickets that you can't verify (e.g. backend or dev ops), leave in Shipped until you can get another dev to verify/kick back to In Progress.
- As you verify tickets, keep an open mind about what's still not working in the overall user flow in that area. Take notes to circle back to.
In addition to checking tickets, you are gauging whether the app that's on Stage is ready to push to production. You should feel confident that what you are testing is an improvement over the app that is currently in front of users.
- Clone the last Sprint document and update the fields or change old text to [xxx] until you can fill it in. Delete the intro text except the boilerplate. Delete the links to the Accepted Tickets. Now you have a foundational doc for the next sprint with the tickets that you thought were priority last sprint, but weren't finished (or even started) in this sprint.
Phase 2: Define the Sprint Goal (Step 3)
- Deeply Think about the Sprint Goal. Given everything that's going on with our customers, users, our long term goals and the business objectives, what's the single most important thing to get shipped to customers/users in the next two weeks? That's the sprint goal. There will be other stuff to do, and lots more that gets done, but everyone likes it when there's one single sprint goal that absolutely has to get done. Having one goal focuses the mind. The sprint, no matter how well it goes, is not successful if the Sprint Goal doesn't get shipped.
The Sprint Goal decision will be mine for the near future, but I would like to hear your take on this first and let's discuss.
I like to add a few bullets to the intro text and/or the developer sections of the Sprint doc that indicate the priorities for the sprint to remind me of the bigger picture before I go review all the current sprint tickets.
Phase 3: Triage and Assign Tickets (Steps 4–10)
- Go back to the Jira sprint board. Sort by developer and look at each ticket in "In Progress". Knowing that context switching and the work might be almost done, is that ticket still important for next sprint? The default here should be "Yes" since you thought it was priority last time and the work is in flight. Switch the ticket to next sprint.
- If you don't think it is priority anymore, discuss with me and Bernie.
- After you've done that for every developer (not Bernie... just leave his tickets alone and not Design, that's covered below), start the process again for "On Deck" tickets. Is that ticket still important for next sprint? "On Deck" tickets have less context switching and wasted work if they drop to the backlog at this point. But you thought that work was important enough two weeks ago to pull them out of the backlog, replicate the bugs, maybe do designs etc. The default here should be "Yes" but the tradeoff here is important because the Sprint Goal must be finished. Knowing what we know now, maybe this ticket should move into the backlog again. Switch the ticket to next sprint or into the backlog.
- If you don't think "On Deck" tickets are priority given the sprint goal etc., discuss with me.
Now you have a more up to date Sprint Priorities doc. But what about all the "To Do" tickets from the current sprint? And the Sprint priorities that aren't reflected in last sprint's tickets? And the Design tickets?
- Start the by-developer process again for "To Do" tickets. Is that ticket still important for next sprint? There is still less context switching and wasted work if it isn't. But you thought those were important enough two weeks ago to pull them out of the backlog, replicate the bugs, maybe do designs etc. The default here should be "No" because I hate just carrying tickets from sprint to sprint. It bogs everyone down. Why didn't that ticket get worked on last sprint? Was it too big? Too confusing? Not important enough actually? Any ticket that carries over for more than 3 sprints should almost certainly be moved to the backlog or rewritten to be more clear and actionable. Nonetheless, the tradeoff here is important because that work was judged important last sprint, but the Sprint Goal must be finished. Move the ticket to the next sprint or into the backlog.
If it's really not important, or if it's a duplicate, or if the work described on the ticket was taken care of by another ticket that did get finished, leave a comment in the ticket and mark it "Accepted".
- Review the Accepted and Shipped Design tickets. Hopefully, these designs are what the team needs to build the Sprint Goal. Ideally, Design is 1-2 sprints ahead of the developers, so that there is enough time to iterate and do user testing on designs.
If that's the case, make development tickets for the new sprint pointing to the design tickets that you've already Accepted. Most of the time, leave these new tickets Unassigned until you can talk with Bernie about who should probably work on them. Add the new tickets to the Sprint priority document in priority order.
If the Accepted or Shipped Design tickets don't align with the sprint goals but you want to try to squeeze them into the sprint, make development tickets pointing to the designs and put them in the Sprint Priorities document. Bernie will help draw the line about how much should get into the sprint based on how much development work is underneath each feature/design. If you think the sprint is too full, make a development ticket for the design and put it in the backlog. This is unfortunate because designs have a short shelf life, but sometimes it can't be avoided. This outcome is definitely better than trying to cram too much into a sprint or building something without a decent design.
- Review the Design In Progress, On Deck and To Do tickets as you did with the developer tickets. In Progress design tickets should likely continue but maybe not. On Deck and To Do likely not, but maybe as described above. It's a good idea to think about overall priorities and talk with Scott about these decisions. Too much design task churn is frustrating. Carrying over too much stuff from sprint to sprint is toxic for productivity. These tradeoffs are the essence of project management.
- Now you have reviewed all the tickets that were not in Shipped at the end of the current sprint, you've decided what to do with them given this upcoming sprint's goal and you've updated the new Sprint priorities document. You've also used the stage version of the app a bunch of times with a fresh mind and you've taken notes on areas that are feeling good and those that still need attention.
Your Sprint doc likely has at least some carry over work, some new development tickets based on all the Design work this sprint, and some bullets for new tickets for hitting the Sprint Goal. Fill out those new tickets (marked Unassigned), create tickets (even if they are placeholders) for your sprint work, and then update the Sprint priorities doc.
- Prioritize the Sprint Priorities document. Based on everything you know, move the ticket titles/links to priority order for backend, front-end, design and product. Now you have a solid first draft Sprint Priorities document to send to me for review. The goal is for you to write something that I feel good about showing to Bernie in our pre-Sprint planning meeting that takes place at the end of every sprint.
Phase 4: Pre-Sprint Planning Meeting (Step 11)
- The Pre-Sprint meeting. This meeting is for:
- Confirming that we should push Stage to Prod. Create a ticket for Bernie to do so if agreed.
- Talking through/agreeing on the Sprint Goal
- Talking about carrying over any In Progress and On Deck tickets
- Reviewing the new tickets in the sprint, adding ones as required to both Jira and the Sprint Doc
- Confirming/Adjusting priorities of tickets within the sprint plan
- Assigning Unassigned tickets at least temporarily. These could change during the sprint.
- Making sure that everyone has enough work and clear priorities.
- Maybe getting Bernie to approve/reject backend tickets that you couldn't review
- Maybe talking through Bernie's tickets. Maybe he can move some to the backlog. Maybe some are done.
Now you have a second draft sprint priorities document. Update it based on the conversations and polish it for emphasis, grammar and clarity.
Phase 5: Launch the New Sprint (Steps 12–15)
- The Jira board for the current sprint should now have very few tickets on it... Double check that it's only showing Accepted tickets and ones that we want to carry over to next sprint.
If anybody has more than five tickets carrying over, see if you can move the balance to the backlog. If not this sprint then almost certainly the next sprint.
There might be a stray "Shipped" ticket that you can't verify and hasn't yet been reviewed by someone who can. That's fine. Send the right person a Slack message with links to the tickets to get them to review it.
The Jira Backlog view will show the new sprint with all the new and carryover tickets in it.
Now you can Complete the Sprint and Move Open Issues to the next sprint.
- Start the new sprint. Adjust the Start and end dates to Sunday night unless something is off about the sprint plan. Change the Sprint Name to the Sprint Goal (or an abbreviation) and summarize it in the text field. Include a link to the Sprint Priorities document to in the Sprint Goal section.
- Double check the Jira board priorities by person. The aim here is that before you send out the new sprint news (see below) each person's priorities match your plans. Never move tickets in or out of In Progress until you've talked with the person working on the ticket. Don't move Bernie's or my tickets.
There might be Unassigned tickets on the board. That's fine.
- Post "Welcome to the new sprint" in General Slack with a link to the sprint priorities doc and the Jira board. Add the link to the priorities doc to the sprint planning calendar invite.