Task prioritization with MoSCoW
|
Prioritizing tasks started to be key activity during our sprint planning meetings. As soon as the student group were approaching to release the alpha, different methods were tried to find optimal way how to prioritize tasks in a sprint. When we adopted Scrum in the student project, we were still continuing in a method we used before, that could be close to Eisenhower box method, which is a relatively simple technique using urgent/important principle, which helped us to think about our priorities, determine which of the task from the product backlog are important in the current sprint and which not. It also helps to avoid procrastination, a common phenomenon among university students. Adopting Scrum, one may ask “What does Scrum say about prioritizing tasks in a team?” Although Scrum explicitly requires to prioritize tasks in the sprint backlog, it doesn’t a priori say how. According to Scrum, the prioritization happens during sprint planning, and priorities can be changed during the sprint under circumstances. But, “How does the prioritization really work?”. To answer this question, it create a requirement for Scrum Master to first find a prioritization method solution that works best for a particular group and project, and promote the method within the group. Finding a proper solution is not always easy. Scrum methodology is usually applied in product development, and can be accompanied with another project management methods, that can already prescribe prioritization that works best for a whole production environment, not only for a particular development team. In case of student groups, the groups had no prioritization method prescribed, which is an opportunity to make experiments to find a working method. From this aspect, Scrum is supportive not rigid methodology, allowing to make shifts in tools and methods during a development process when necessary.
For example, one week before the alpha sprint, there was an important decision point in the project, when one member had to leave the group. As there were less than 2 weeks before the alpha release, the group changed the way of prioritization, and adopted MoSCoW. MoSCoW is a technique for helping to understand priorities according to goals. The letters stand for (M)ust Have, (S)hould Have, (C)ould Have, (W)on’t Have in the sprint. That prioritization can be applied to requirements, tasks, features, use cases, user stories, acceptance criteria, or tests. In our project we had the timeboxed sprint to one week, thus understanding the relative importance of things in the sprint was crucial to making progress and keeping to deadlines, especially the alpha release. However, MoSCoW de-facto transcribe meaning for key words Must, Should, Could, and Won’t, and that require careful interpretation of these words by all Scrum team members. MoSCoW language may sound more demanding, and its application can be disruptive for less experienced groups. On the another hand, it requires personal commitment and individual responsibility to finish promised tasks in priority order, especially for Must Have tasks. Prior to requirements capture, the definitions of Must Have, Should Have, Could Have and Won’t Have need to be agreed with the team. The Must Have definition is not negotiable. Any requirement defined as a Must Have will have a critical impact on the success of the project. To conclude, using MoSCoW in our project for already tree continuous sprints, we successfully delivered the alpha in time and in MUST level (i.e. Minimum Usable SubseT), specified by the course syllabus. Moreover, using MoSCoW allowed us to plant the sprints more constructively and responsively. Possitive effect of using MoSCoW in the project is already indicated by higher sprint review done ratio than was before. However, it’s too early to evaluate benefits and effects of using MoSCoW in the project, and more sprints have to be reviewed.  |
