Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products.
I was assigned this book as one of the “texts” for my content strategy and social media class. This is my favorite class of the semester, so I ordered all the books and have been excited about diving in and reading them (which is odd, because I typically don’t read textbooks), but I feel this class is super pertinent to what I hope to do when I graduate. With that being said, it is important to realize that I read this book without any prior knowledge on SCRUM methods or any understanding of what Agile even is.
From what I read, I gathered that SCRUM are methods based off of Agile, that helps small teams get stuff done. The author uses the methods in terms of software production, but claims it can be implemented for any line of work. The title calls this a breathtakingly brief introduction and brief it was: less than 50 pages!
I liked that it was small, so reading it didn’t feel so daunting and overwhelming. The author also uses very concise writing as to not clutter and drone on and on. I feel in a lot of works where someone is trying to explain a system they overthink it and in the end explain to much, but I this was short and to the point which is a great example for technical communication.
Two ideas they showcase in the SCRUM model that I want to implement in my own work as well as any teamwork I am assigned in the future are the task board and the definition of done. The task board is a simple way of categorizing items: to do, doing, and done. I kind of already do this, but I just think it is an easy and useful way to keep everyone on the same page. If all the items for a project are on that board then no one can say they didn’t know it needed to be done or was already completed. The definition of done was an important one to me, because the author talks about how different people feel like a project is considered done at different stages. He recommends discussing this idea with everyone and coming to a common conclusion as to when the project will be done.
My only complaint or minor irritation about this introduction to SCRUM was the need to call things multiple different names. For example: backlog items or user story. They used these interchangeably throughout the whole book and it confused me. I think that in such a concise method, the same terminology needs to be used throughout books on the topic as well as execution in the field. They talk about users and “story time,” so calling the items user stories makes more sense to me, although I still do not fully understand how a user story actually works or should be worded.
Bottom Line: For an extremely quick and concise introduction to simple methods, this book was easy to read and pretty easy to understand. I feel like I have basic knowledge on the SCRUM system now and am ready to begin implementing it into my work. Although it is a small book and a quick read, I recommend taking your time and really trying to visualize how these methods work and can be executed in your own line of work. I would recommend this for anyone who frequently works in teams or is struggling to stay on task and execute projects.