It's iterative, in that you repeat the same steps over and over (planning, review, etc). It's incremental in that at the end of each iteration, you have a working product--it may not do everything you eventually want it to do, but it works. It's agile in that you can easily change direction as needed--a new technological development, in the software world, or a new water heater in a home. It's intended for software development, but screw that, I'm using it to run my house.
Scrum, in a nutshell, works on the following:
There is the product, which is the agreed-upon common goal we're all working towards. In the software world, it's the game, or the application, or the operating system. For us, it's a happy and fulfilling life.
There is a product owner, whose job it is to direct the product, and figure out which goals, or stories the group is going to work on, and arranges them by priority, so the very most important things are done first. This ordered list is called the backlog. In software development, there's only ever one product owner for any given product. In my house, there's two. Every decision is made by consensus.
A story is a problem that needs solving, or a goal that needs reaching. The product owner defines the need, and the acceptance criteria, the minimum requirements to meet the need.
Once the stories are arranged in order of importance, they're passed on to the Development Team. They're the ones that actually get the work done. But because they're doing the work, they also determine what defines "done" for each story, and assess both how much work they think each story is, and how much work they can get done, as a team, during one Sprint.
The Sprint is both the work that is done, and the amount of time taken to do it. Remember that "iterative and incremental" bit up above? Scrum is one sprint immediately after another, forever, so that's the iterative part, but stories are constructed so that they're done at the end of the sprint, so it's incremental. (There may be epic stories, which span months, but they're broken into small, manageable, finishable and working pieces.)
Stories from the backlog are assigned points, by consensus (more on this process later), and then the top however many stories are taken for the sprint.
Finally, at the end of the sprint, there's the Sprint Review and Retrospective, but I'm not ready to explain those yet.
Here's how it's working for us: Our product is A Happy and Fulfilling Life. As product owners, we made a long list of things we’d like to do, or need to have, to work toward that goal. Everything went on index cards, which we arranged into priority order. It’s really important that we have dinner at home once a week, for example, but it’s even more important that the litter box stays clean so that the cat doesn’t poop on the floor. Each item is a story, each story has minimum criteria (story: litter box. Criteria: clean enough to keep the cat happy.)
Then we magically transform into the development team. We assign points to the stories we think we're likely to get to, based on how much work we think each thing is. This isn’t just time required, it includes actual effort as well as mental blocks. The litter box is icky, so it has more points than another job that takes just as long. or is just as hard. Points are assigned by consensus. We know roughly how many points we can handle in a week, which is the length of our Sprint, so we look at the backlog, and take as many stories as we should be able to handle. At the end of the sprint, we look at how things went.
It’s all consensus-driven. We agree how much work things are. We commit to each other that we will try HARD to get all the work done that sprint. We’re accountable to each other and ourselves.
There’s a lot more to it, and I’m only just starting to understand how it all works.
Next up: Finding a backlog
No comments:
Post a Comment