How it works¶
- Table of contents
- How it works
Before we begin, it would be a good idea for you to make sure you are a bit up to date on the SCUM methodology. No need to be the finest expert here but you will need to have the basic understanding of the method.
To help you on that, I recommend you to watch some of the videos from here: http://scrumtrainingseries.com/
You will especially need to understand the following concepts:
- Product Backlog Item (PBI) means a goal to achieve, it is not meant to describe precisely any task to do, but rather a user story to achieve. They are supposed to be reasonable in size (that is, effort), and concern only one type of feature.
- Task this is the subdivision of a PBI (to achieve a PBI you will have to perform tasks).
- Product Backlog: This is the list of all PBI (goals) that you ever want to acheive
- Sprint: this is the period of time (must be here again small enough, and never more than one month) during which you will work on tasks without resorting to any change in the planning (really, kinda sprinting toward a goal).
SCRUM process at a glance¶
SCRUM methods is somehow split among these different roles:
- Product Owner: the person responsible for defining goals (PBIs) and their importance
- Scrum master: the person responsible to watching over the methodology itself
- Team: well, the ones actually doing the work (in very small teams, all of those can be in fact the very same person)
- Reviewer: a team member responsible for checking a specific task completion. (here again, in small team, it can be the same person)
Basically it all boils to:
- The product owner defines PBIs and add them to the product backlog
- The Scrum Master defines a Sprint (name, start date, end date)
- The product owner defines what are the most important goals to achieve
- The team will then add goals to the Sprint, and define tasks for each goals
- When the Sprint is full (that is, it has enough task to fill the sprint effort), the sprint is closed and it starts
- Team member pick a task from the springboard and move them to "In Progress" when working on it, then "Resolved" when done
- The reviewer take the resolved task and check it, when done, he moves it to closed
This goes on till the end of the sprint or the end of all task (whichever comes first). Tasks/goals not done on one sprint can be moved to the next one although it means that next planning should include less task as normally all task in a sprint are supposed to be completed by the end of a sprint (Also exactly how you decide the flow is on your own, the 3 last steps details are only an example, and happen to be the method I have chosen, more on that later).
Now that we are all set, let's explains some bits of the configuration:
PBIs and tasks¶
If you want the SCRUM plugin to work well, you will need some structure to your redmine.
SCRUM plugin will need to make the difference between tasks and PBI. For this, the best way is to place all your PBI in a tracker. (I decided to create a tracker named "Goals" for this purpose). Go to your SCRUM plugin configuration page:
We will start off by activating the "Render Scurm plugin tips", (which is an attempt to help you configure properly this plugin), and head straight to the PBI Tasks configuration:
Find the Product backlog items menu and select the tracker from which the PBI will be retrieved:
(my theme may look a bit different than the one on your classic redmine installation, if you are interested I use minelab theme: https://github.com/hardpixel/minelab)
You can select multiple trackers for the PBI and for the tasks. (It is usually not a good idea to have the same tracker serving both purpose, but it is nevertheless possible in this plugin).
This page is still under construction, more to come soon