Good morning sunshine day ☀️🤩 In Bangkok now, the weather is great ~ it’s around 20–28º C all day, hopfully, the good weather like this will be with Bangkokers until end of Feb 2023.
When talking about good things, I’d love to start a day with my wonderful memories about a brilliant training in Singapore. Yes, it’s CSPO training, let’s continue😁. After learned about Scrum concept in CSPO training day 1, all about software products and the sprint concept, the next topics are prioritization, definition of done and project estimation.
When it comes to prioritization, there are tremendous frameworks; sometimes I call them as tools, to order tasks before put them into the sprints. In this class, I learned one framework of those and I think it’s one of the most popular because its simply and easy to apply. Can you guess it? The answer is “MosCoW” prioritization.
MosCoW prioritization
When listing PBIs or items the team needed to implement, surely that the team can not implement them all by the fixed time; aka deadline. Then using MosCoW framework will help the team to list items they should implement ordered by its values from highest to lowest that will impact or align with customer needs.
Typically, there are 3 main groups of tasks including
- Must have
- Should have
- Could have
Hence, some POs usually refer to “Return On Invest metric or ROI” that evaluated from value; calculated from business impact i.e. estimated sale amount, cost saving amount etc. and team’s effort taking to implement each item; commonly estimated by how long does it take to complete the task in man-hours. After that PO will put the ordered items into the pipeline, and do the sprint planning.
Before starting implementation, the team should set their definition of done (DoD), for example, the team will mark a particular item or feature as done when they can meet all of these; coding is done, document is updated, testing is completed and passed100%, the item or feature is accepted by PO.
Meanwhile, each sprint or development iteration also needs to define its goal, aka sprint goal. Moreover, after started implementing, the team should keep monitoring on the tasks’ progress, its impediments and lesson learned from each iteration also improve team’s process by sprint retrospective ceremony, and recheck the outcome whether it’s still align with the product goal or not with sprint review ceremony.
Consequently, PO is able to use the “Burndown Chart” to see the team velocity, and foresee the project release plan whether the team can deliver all item list as it planed at the beginning or not.
Actually, there are some topics that Pete shared and encourage the class to practice and discuss, in pair. In my opinion, this training session was wonderful, I had learned about what the theory is and how to apply in real life projects. Overall, everything Pete touch, guided and shared in the class those all are easy and able to apply in daily work easily 👍🤩🥳
