METHODOLOGY – SCRUM
For our final project, marketing for the West End Festival, we are using the scrum project management methodology. I hadn’t used this methodology before so I had to do a bit of research (because I don’t really remember all the details from when we learnt it in Tri 2).
This is what I found out about the Scrum method:
- Product Owner: this would be the client
- Scrum Master: pretty much the team leader
- Team: the team of designers working on the project.
- Product Backlog: a complete list of the collateral that’s to be done throughout a project, ordered in priority according to the product owner so that the team is working on the most valuable tasks first.
- Sprint Backlog: this is a prioritized list of tasks the team needs to complete during the sprint. Worked out in the Sprint Planning Meeting.
- Burndown charts: this is used to show the amount of work remaining in a sprint. It will be an effective way to determine at a glance whether a sprint is on schedule.
- Sprint Planning Meeting: there will be a planning meeting at the start of each sprint to discuss the work to be done. Through email, the product owner and the team determine the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to complete during the sprint.
- Daily scrum: each day during the sprint team members share what they worked on the prior day, will work on today, and identify any impediments. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint. These meetings should be no more than 15 minutes.
- Sprint Review: at the end of a sprint the team presents the work they’ve done. The goal of this meeting is to get feedback from the product owner and any users or other stakeholders who have been invited to the review.
- Sprint Retrospective: at the end of each sprint the team reflects on the sprint that is ending and identifies how they can improve in the next sprint.
This is just a good visual of how scrum should work:
I’m just going to outline some of the problems we had with this methodology:
- We chose scrum but we didn’t really know the correct way to set up all the documentation.
- We didn’t have a complete list of jobs that we had to do until at least the end of the second sprint but the first meeting we were supposed to have was a meeting to create the product backlog and prioritise each item on the list.
- For each sprint we were to have a new table outlining what would be worked on that week. We kind of had this at the end of the second sprint but it was not right because it was continually updated as we went instead of having a new sheet for each sprint.
- So, as you can see all of our documentation was wrong and we have had to fix it all up. This means that we are madly working to fix these and at the same time, finish off collateral and work for other projects. Crazy, busy at the moment. We have since done more research, and with input from our teacher, are on track to getting all our documentation correct.
- One website mentioned having the tasks for a sprint listed on a whiteboard – I think that would be a good idea for our next project. Just having it written up and visible to all group members would be a really great thing.
- We also weren’t having the meetings as we were supposed to be. As I already mentioned we didn’t sit down at the start and write up a prioritised log of each task to be completed. This is a very important meeting to have as it would have allowed us to see what needed to be done from the start and tasks may have been easier to allocate to each team member.
- Now, it’s a bit seems hard/wrong/silly (I’m not sure what the right word to use here is…) to talk about how we haven’t been using the methodology in the right way because we have completed all of our tasks and achieved a number of desirables as well. But that doesn’t matter, we did do it wrong. As I thought about it a bit more, it occurred to me that we may have been able to achieve and complete a lot more desirables for the project (if we had done the product backlog at the start, we could have estimated the times for each task, realised some tasks won’t take long at all, brainstormed more collateral we could work on and add them to the list too). We may have also had a lot of fun creating and designing collateral we may not have had a chance to yet.
- We chose a project manager but I’m not sure they understood what it meant to be in that role. They should have been the one to make sure we were doing all the correct things as per the methodology but they weren’t. Also, no one else questioned if we should be doing things any different either. I had written the section in the project plan about scrum specifically and I remember saying something once but it kind of got brushed aside and I didn’t broach the subject again. This is definitely something I need to work on.
I had created some of the artefacts but I’d just been doing them wrong. Once we got them right though, I found the artefacts used in the scrum methodology to be really useful. Creating a complete and comprehensive list of all the collateral that needs to be done is a really helpful tool to use. Also, the ability to prioritise tasks within the list is really important. Having a list written up is a really good way to visually be able to see what needs to be done. Creating it as a table in a program like Excel also means it is editable, easily updatable and it makes it super easy to also create the burndown chart. Now the burndown chart is also a really good tool. This is a visual representation of how the whole project is going. This article (Understanding the Scrum Burndown Chart) explains all the ways these charts can look like and what it’s saying about the team.
So what did I learn.
- It is really important to know each aspect of the methodology (sit down as a group and go through it at the start so everyone is on the same page)
- Even if it may seem silly, have the required meetings (everyday)
- Produce the right documentation. This will ensure that we are being as productive as we can be.
- Personally, I need to be more assertive, especially when I know we aren’t doing things right.
See the reference list for a few of the websites I looked at. If you want a bit more information, they all go into more detail.
Cohn, M. Scrum methodology and project management. Retrieved May 5, 2016, from Mountain Goat Software, https://www.mountaingoatsoftware.com/agile/scrum
James, M. (2013, May 9). An empirical framework for learning (not a methodology). Retrieved May 5, 2016, from http://scrummethodology.com
Kocurek, D. (2011). Understanding the Scrum Burndown chart. Retrieved May 5, 2016, from Methods and Tools, http://www.methodsandtools.com/archive/scrumburndown.php
Layton, M. C. (2016). Agile project management: Five elements of a sprint. Retrieved May 5, 2016, from http://www.dummies.com/how-to/content/the-function-of-the-scrum-and-sprint-within-an-agi.html
VersionOne. (2016). What is Scrum project management & Scrum methodology. Retrieved May 5, 2016, from Keyword Page, https://www.versionone.com/scrum-project-management/