0. In Jira, create a new sprint with an incremented number and a generic description.

1. 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.

2. 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.

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.

4. 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.

5. 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?

6. 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".

7. 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.