Scrum is a very popular software development method used by software engineers that prioritises project planning and team management. When I first came across this, my initial thought was, quite obviously, which points are important for the upcoming exam. My very next thought, after thoroughly reading it, was that this had quite a few nifty features for managing any kind of group projects, academic or otherwise. If you're interested in easing your own group projects, then I suggest you read on.
Before jumping into Scrum's normalized implementation, let's first see what the real software-based Scrum is all about. The Scrum model, by nature, is quite simplistic. It emphasises on modularity for better management. The first modularization comes in the form dividing the software's requirements, namely its features. These are called User Stories. The User Stories are listed and prioritized. The Stories together are called the Product Backlog. This is, in simple terms, a collection of tasks to complete to finish the project.
The next modularity is in development sessions called Sprints. A Sprint is a 3-4 weeks long period in which, ideally, a shippable software is produced, with earlier Sprints used for prototyping. Every Sprint takes selected User Stories from the Product Backlog based on priority points. This selected collection is called the Sprint Backlog. At the end of a Sprint, the unfinished or partially finished User Stories are edited and put back to the Product Backlog for the next Sprint.
Now, during each Sprint, the User Stories of the Sprint Backlog are turned into tasks and each task is assigned to a team member. A Sprint has a few defined states for tasks, like “To-do”, “In Progress”, “Done” and more. The assignees can put their tasks in any of the states and change states when required. The team uses a board and post-its or online tools to display the tasks and their progress in columns. This way, everyone in the team can view the current progress of the whole project and how much everyone is working or contributing.
Scrum's most signature aspect, in my opinion, is the Scrum Meeting. Every day during a Sprint, the team members must physically gather and have a quick-fire meeting in 15 minutes. The meeting is coordinated by the Scrum Master, who can be one of the members. This meeting is mandatory for the members and absence would mean punishment, the non-violent sort, like donating to the team's fund for a post project grand feast. A Scrum Meeting consists of team members taking turns and answering three questions- “What have you done since the last meeting?”, “What are the difficulties you are facing?” and “What is your goal until the next meeting?” Scrum Meetings are a great way to share development troubles and answer for one's lack of work.
The key to using Scrum for regular assignments is to tweak and modify the rules of the original Scrum to your favour. For example, you can refer the User Stories as the different aspects of writing a report, like interviewing, literature reviewing or writing the appendix. The length and number of Sprints can also vary. The 3-4 week length is usually applied for year-long projects. Modify the length of Sprints based on the size of your project. If it's a very small project you can just work with one Sprint. Lastly, you can modify the frequency of Scrum Meetings. If daily meetings are difficult you can opt for biweekly ones. If meeting up physically is also not possible, then there are always online video conferences.
As you can see, Scrum is no profound innovation stemmed from mankind's collective creative genius. But it still is a useful structure for team management. And when you're a group leader with a not-so-reliable team, I strongly believe Scrum will be the effective tool to save the day, and the project.
Fatiul Huq Sujoy is a tired soul (mostly because of his frail body) who's patiently waiting for Hagrid to appear and tell him, “Ye're a saiyan, lord commander.” Suggest him places to travel and food-ventures to take at fb.com/SyedSujoy.