Scrum implementation in TrackStudio
This is an article about how using TrackStudio you can lead software development according to the Scrum methodology. TrackStudio is a universal task management system and Scrum is one example of use. You will need a copy of TrackStudio ( 90-day trial version ) and configuration . After downloading, you need to install TrackStudio and roll over the configuration instructions.
In accordance with the Scrum methodology, three roles are defined in the system: Product Owner (Customer), Scrum Master (Master) and Team (Team).
The task of the Product Owner or Customer is to register in the history system and determine their importance for the product. The customer interacts with the team (Team) for the most complete understanding of the Customer’s goals by the team, and the Customer - the team’s capabilities The result of this interaction should be clearly formulated and ranked in importance stories that the Customer and the team understand in the same way.
')
The master is a bridge between the customer and the team, he plays the main role in planning the sprint, determines his budget and distributes the stories on the team.
When planning, each member of the development team assesses those tasks that he understands, indicating the task budget in hours. Upon completion of the planning, each participant deals only with his tasks.
The system defines projects, histories, sprints and tasks. Projects are in charge of the Customer. He writes stories. Sprints creates a master, he fills them with stories. Tasks can be created by team members inside sprints and inside stories.
The customer creates stories as fully and clearly describing them. At the same time, the “How to demonstrate” and “Importance” fields must be filled. In the "Importance" field there should be any integer, the larger it is, the higher the importance.
The team then reviews the tasks created by the Customer and assesses their workload, indicating the budget. At the same time, team members see each other's marks and can be guided by them, or do not see and rely only on themselves.
The system prompts which tasks have already been evaluated by this participant, and which have not.
Unlike the traditional Scrum methodology, the Customer does not determine the complexity of the implementation of the story, but sees estimates of the complexity and can participate in their discussion.
The wizard creates a sprint in which the Customer indicates the deadline in the discussion with the Wizard and the team. By the deadline, the sprint should be ready for demonstration. Based on the timing and performance of the team, the master specifies the sprint budget. However, he focuses on the indicator "You can schedule" in the "Planning" table in the sprint. The sprint budget should be less than this estimate.
After all or almost all participants have evaluated the stories, the Master begins to fill in the sprint, transferring to it the most important tasks for the Customer. The budget of the stories at this stage is not approved, it is still a matter of discussion. Transferring the history to the sprint, the master sees the first estimate of the sprint budget and compares it with the given one. At this stage, you can already imagine which stories will be included in the sprint, and which - not.
Then the wizard starts distributing stories by performers and approving task budgets.
At the same time, he can be guided both by the estimates of the team members, choosing as the responsible person who indicated less time, and by the team workload table. The budget at the same time the Master can specify, based on their estimates.
Sometimes the user entering the team works not only on the project of this Customer, but also on other projects. In addition, in some teams, different users work a different amount of time (not everyone is at work from 9 to 18). To take this into account, for each user there is an additional field “Employment rate”. It indicates the number of working hours per user per week. Those working hours when working, and not present at work - this is important for planning sprints.
After the distribution of the tasks of the sprint, it may turn out that some of the participants are “hanging” more tasks than they can complete. In this case, you need to either revise the budgets of the history of this participant, or reassign part of the tasks to another participant, or decompose the largest tasks and distribute them to the team.
Also, of course, it may turn out that the "party budget" in planning has been exceeded. In this case, you should either increase the sprint budget (if the time reserve allows it), or change the estimates of a part of the stories, or remove some of the least significant stories from the sprint.
At the end of the sprint planning wizard starts the sprint at work and the team can proceed to their tasks.
The wizard can monitor the progress of the sprint and respond to the backlog in a timely manner. If more than planned time was spent on the history, this time will be marked in red. When a team member performs all his tasks, the master can reassign tasks to him to other participants who are behind schedule.
After all the stories in the sprint are implemented, the wizard will be able to close the sprint and, together with the team, proceed to demonstrate the results to the Customer.
In accordance with the Scrum methodology, three roles are defined in the system: Product Owner (Customer), Scrum Master (Master) and Team (Team).
Product Owner
The task of the Product Owner or Customer is to register in the history system and determine their importance for the product. The customer interacts with the team (Team) for the most complete understanding of the Customer’s goals by the team, and the Customer - the team’s capabilities The result of this interaction should be clearly formulated and ranked in importance stories that the Customer and the team understand in the same way.
')
Scrum master
The master is a bridge between the customer and the team, he plays the main role in planning the sprint, determines his budget and distributes the stories on the team.
Team
When planning, each member of the development team assesses those tasks that he understands, indicating the task budget in hours. Upon completion of the planning, each participant deals only with his tasks.
Backlog
The system defines projects, histories, sprints and tasks. Projects are in charge of the Customer. He writes stories. Sprints creates a master, he fills them with stories. Tasks can be created by team members inside sprints and inside stories.
How it works
Filling the product backlog
The customer creates stories as fully and clearly describing them. At the same time, the “How to demonstrate” and “Importance” fields must be filled. In the "Importance" field there should be any integer, the larger it is, the higher the importance.
The team then reviews the tasks created by the Customer and assesses their workload, indicating the budget. At the same time, team members see each other's marks and can be guided by them, or do not see and rely only on themselves.
The system prompts which tasks have already been evaluated by this participant, and which have not.
Unlike the traditional Scrum methodology, the Customer does not determine the complexity of the implementation of the story, but sees estimates of the complexity and can participate in their discussion.
Planning
The wizard creates a sprint in which the Customer indicates the deadline in the discussion with the Wizard and the team. By the deadline, the sprint should be ready for demonstration. Based on the timing and performance of the team, the master specifies the sprint budget. However, he focuses on the indicator "You can schedule" in the "Planning" table in the sprint. The sprint budget should be less than this estimate.
After all or almost all participants have evaluated the stories, the Master begins to fill in the sprint, transferring to it the most important tasks for the Customer. The budget of the stories at this stage is not approved, it is still a matter of discussion. Transferring the history to the sprint, the master sees the first estimate of the sprint budget and compares it with the given one. At this stage, you can already imagine which stories will be included in the sprint, and which - not.
Then the wizard starts distributing stories by performers and approving task budgets.
At the same time, he can be guided both by the estimates of the team members, choosing as the responsible person who indicated less time, and by the team workload table. The budget at the same time the Master can specify, based on their estimates.
Degree of employment
Sometimes the user entering the team works not only on the project of this Customer, but also on other projects. In addition, in some teams, different users work a different amount of time (not everyone is at work from 9 to 18). To take this into account, for each user there is an additional field “Employment rate”. It indicates the number of working hours per user per week. Those working hours when working, and not present at work - this is important for planning sprints.
After the distribution of the tasks of the sprint, it may turn out that some of the participants are “hanging” more tasks than they can complete. In this case, you need to either revise the budgets of the history of this participant, or reassign part of the tasks to another participant, or decompose the largest tasks and distribute them to the team.
Also, of course, it may turn out that the "party budget" in planning has been exceeded. In this case, you should either increase the sprint budget (if the time reserve allows it), or change the estimates of a part of the stories, or remove some of the least significant stories from the sprint.
Launch
At the end of the sprint planning wizard starts the sprint at work and the team can proceed to their tasks.
The wizard can monitor the progress of the sprint and respond to the backlog in a timely manner. If more than planned time was spent on the history, this time will be marked in red. When a team member performs all his tasks, the master can reassign tasks to him to other participants who are behind schedule.
After all the stories in the sprint are implemented, the wizard will be able to close the sprint and, together with the team, proceed to demonstrate the results to the Customer.
Source: https://habr.com/ru/post/101403/
All Articles