--- tags: sprint planning, tezos title: How to prioritize tasks --- # How to prioritize tasks ## Priority Matrix ![Priority Matrix](https://i.imgur.com/Kqs6zqh.png) ## How it works In the above priority matrix, we have `Priority` on y-axis and `Difficulty` on x-axis as these are the 2 factors that influence when a task moves from backlog to a sprint. Task selection moves from left to right and top to bottom so tasks with `high priority and easy to do` get picked first and tasks with `low priority and difficult to do` get picked up last. During the backlog refinement process, it is the job of the Product owner to decide and prioritize the tasks and the job of the team as a whole to decide the effort the task requires. Both of these things, Priority & Difficulty, position the task on the priority matrix. ### Important points: **Priority** can only be changed during backlog refinement i.e. before a sprint starts. **Difficulty** can be changed in-between the sprint but before a task has been moved from `ready` to `in-progress` state. ### How to 1. When creating a task select the `Task template` ![](https://i.imgur.com/izEaQXT.png) 2. Now edit the task to add the details ![](https://i.imgur.com/glRgGV7.png) ### Fibonnacci/Scrum Estimation If a task requires a difficulty estimation a fibonnacci estimation technique can be used in refinement. 1. With a group of several developers start a fibonnacci estimation round. you can use https://firepoker.io/#/ or post-its to write the difficulty. 2. if using a fibonnacci sequence you should set an upper limit of story difficulty to decide when a story is too big and should be split. For Example 20pts. 3. Detail a story for the group and then do an estimation round to see what people think the difficulty is. 4. If there is agreement then assign the difficulty. 5. If not, ask participants for information why they think it is _that_ difficult and then vote again. 6. The goal of using estimation is to gauge velocity for a sprint. At the end of a sprint the total amount of story points should be tracked to find average velocity sprint to sprint. 7. This is useful to understand and estimate the expected amount of work that will be finished. #### Point to Time Comparison (per person) - 0 = around 1 hour of work at most. - 1 = less than 1 day - 2 = around a day, possibly more. - 3 = 2-2.5 days. - 5 = 4 days. - 8 = more than a week. - 13 = most of a sprint (7 to 9 days) - 20 = more than a whole sprint. this should be split If something goes terribly wrong: - 40 = this is crazy big, even several people wont finish this in a sprint. equivalent to creating the whole hackathon portal. if this number comes up in estimation it is a problem.