In scrum a story is "Done" when it meets the team's shared "Definition of Done". The definition of done is roughly a list of requirements that all parts of the software increment must adhere to to be called complete. Like most things in scrum the implementation details are left to the team to decide. When I was first working with scrum I had a hard time finding examples of what a typical definition of done would include. Most scrum authors (and even many trainers) wave their hands and say that it's too specific to the team and their environment to generalize.

We've been having some discussions at $DAYJOB about process and methodologies. The topic of late is scrum and how it may or may not be helpful for the particular group I work with. I've been providing some anecdotal input based my past experience with scrum and other methodologies/frameworks/practices and asking questions about what problems the group is hoping to find new solutions for.

I started to write a big wall o' text™ email about a particular topic and then decided that maybe a blog post would be a better way to work through my idea. So dear reader¹, here are some of my highly opinionated and mostly unsubstantiated thoughts about a process that a group of people could use to plan a scrum sprint (or really any other iterative unit of work).