During my previous sprint, I have put a lot of focus and energy into writing, rearranging and organizing my group’s Scrum document to make sure that every member knew exactly was has to be done to finish the project, as well as to reduce time spent individually on browsing the backlog by each person involved in the project.
Firstly, I have gathered the group in order to collectively create a catalog of most artifacts which had to be included in the final product. Secondly, I have individually updated the backlog with help of a casual interpretation of the MoSCoW method (without the “won’t” part), by identifying and categorizing each possible artifact or asset that was missing from the original version of the document, which was earlier written together with the rest of the group. Furthermore, I have later discussed all newly added artifacts with the group, in order to make sure everything has it’s purpose in the project.
Additionally, I chose to make certain changes to the document itself, as I have felt that the template provided by the course wasn’t sufficient enough to meet my needs. These changes weren’t too major, however I believe they could help preventing miscommunication among the team members throughout project’s duration. These changes were mostly visual, nonetheless in my opinion it’s of high importance for this kind of documentation to be very clear and easy to maneuver through, especially since certain responsibilities within both the sound and art department are most likely to be shared between multiple people due to small size of the team. Improving readability of the Scrum document will allow the group to focus more on work rather then wasting time by scrolling through pages of poorly organized documentation. These changes include the following: assigning unique colors to each type of responsibility (Code, Art, Design, Sound, Management and Group) with clear and coordinated structure, to allow multiple people to contribute to various roles (for example, if the Lead artist was in need of help in finishing a certain asset, or when certain tasks would require contribution/presence of all group members simultaneously), making a clearly visible distinction between each sprint, and creating a template for further weeks to allow members to focus on planning rather then technicalities of the google sheet.
To conclude, my goals during this sprint were to improve clarity of documentation and improve workflow of each team member. Following weeks will show if my goals have or haven’t been met.
MateuszS 
Hey, good post!
I felt like everything was clearly described, of course I’m no project manager so stuff like the moscow method is alien to me, but I’m sure that to a PM it would be fine. You talked in great length about your motivations, which I understood perfectly. As a member of a team, I indeed want documents which are as clear as possible, and small stuff like visual representation seems trivial, but is crucial.
I only wish you would’ve provided images. Actually seeing the scrum document before and after the changes would have improved the value of the reflection. Indeed, that way, I could’ve seen how to reorganize a document, instead of just knowing that I ought to do it!
LikeLike
It is very clear what you have done and how it is done. I like that you have taken in what we have learned during the project management course and trying to implement it, by using MoSCoW. It is also very good that you are being agile and changing and adapting from the original scrum document we were provided with, to be able to do a better job.
Things to improve is to tell the reader the changes (in this example) that you did, before saying the reasons, because this can help the reader visualize what it is you mean and are talking about more clearly.
Otherwise it is very clear why it is done and it contains some points of value that I can take with me to think about in my own group.
I hope that you are able to make a blog post where you can discuss how these changes helped and or hindered different parts in your project at later date.
LikeLike
I since talked to my Scrum Master about the MoSCoW method, and can now understand what you meant in your second paragraph. For our backlog, we don’t categorize items as must/should/could/won’t. Rather, we just have alpha/beta/release priority. Maybe converting to your method would make it easier to know what items should be prioritized.
LikeLike