Here is part three of the multi-part series on Scrum and Presentation Design.
Check out Part 1: Intro to Scrum here.
And Part 2: Vision, Constraints and User Stories here.
Step 3: Sprint Planning
When we get to Step 3 we have figured out what our vision is, what our constraints are and we have created prioritized user stories. In Step 3 in Scrum we will look at our list of user stories (project backlog) and determine how many of the items in the backlog we have capacity to complete in the next cycle or sprint. We must estimate the amount of work needed for the various items. In a software project the team is doing this. Once the team has determined what items to work on in the next sprint they take those user stories and break them down into tasks.
If we do have a team working on the presentation the team would look at the list of user stories and decide how much they could do in the next sprint and create tasks from those user stories, just like in regular Scrum.
If you are working alone you do the same thing, you decide what user stories you think you can complete in the next sprint. It is basically like saying, I am going to work on this in the next x weeks (or whatever time period you decide for your sprint). You wold then break those user stories into tasks which is basically the same as a to do list. For example creating a color scheme is a task or researching fonts is another task.
Step 4: Sprint
In a software development project a sprint is typically 2 to 4 weeks long. In the Sprint Planning the team decides what user stories they think they can finish in the sprint.
In our presentation design world a sprint of 2 to 4 weeks might be too long. If we think of writing a speech then we have to have an opening, a body and a conclusion. Maybe we need three days to come up with an opening. The point is that it probably doesn’t take 4 weeks so you must decide on a sprint length that makes sense for your situation.
Now is a good time to remind you about the purpose of Scrum; To reduce risk. Since a software development project might go on for a long time before version 1 is ready there are many things that might change such as user preferences and technological advances. By breaking the work into sprints it is possible to get parts of the product in front of users for their feedback and quickly change direction if necessary. If we completed the whole project with no feedback then we will have spend months developing something people might not want and it will be very difficult to change direction or get a do-over.
Back to our presentation design world. By breaking down our work into sprints we also have the ability to get feedback from potential users, audience members. Let us say that we are writing a speech and in one sprint we create the opening. We can then in Step 5 test that opening on different people to get their feedback. If it doesn’t work then we can change it. If we didn’t do this we wouldn’t know until we were in front of our actual audience, which would be too late.
Another example could be if we are developing slides and we create our color scheme in one sprint. We can then test those colors on potential audience members to get their feedback. If needed we can change. If not, great.
Step 5: Sprint Review
The Sprint Review consists of two parts; one is presenting the implemented features to potential users and the other is a retrospective to evaluate the effectiveness of the team.
We have already touched on what the first part means in the previous section. We would get the parts we have completed in front of potential audience members to get their feedback and response. Maybe you have a particular story you have written that you want to include in your presentation. In your Sprint Review you could tell the story to potential audience members to get their feedback and gauge their response to the story.
In terms of the second part of a Sprint Review, the retrospective, in a presentation design project if you are working alone you can use this to evaluate your workflow, your sources, your procedures etc. If you are working with someone else, maybe a graphic designer then you would also discuss such things as communication within the team. Or maybe the sharing of documents and resources. Is it working well.
The point is to figure out what things are working really well and what can be done differently to be more efficient.
Once you have completed your sprint review you implement any changes to your process and start a new sprint working down the project backlog. That is, choosing a new set of user stories from the project backlog and working on those. You will then iterate like this until you have completed your presentation design. At this point you will be ready to deliver your presentation.
Stay tuned for the fourth and last part of this blog post series.