Daily standup: Difference between revisions
Ceopediabot (talk | contribs) m (→Daily Scrum in practice: Typos, typos fixed: eg. → e.g.) |
(The LinkTitles extension automatically added links to existing pages (<a target="_blank" rel="noreferrer noopener" class="external free" href="https://github.com/bovender/LinkTitles">https://github.com/bovender/LinkTitles</a>).) |
||
Line 34: | Line 34: | ||
In order to visualize the progress of works, the Development Team often meets at the [[Kanban]] [[board]] where tasks are shown in the columns representing their state. Increasingly, the table is in electronic form, showing the status in Kanban boards being part of the electronic [[system]] supporting task management. | In order to visualize the progress of works, the Development Team often meets at the [[Kanban]] [[board]] where tasks are shown in the columns representing their state. Increasingly, the table is in electronic form, showing the status in Kanban boards being part of the electronic [[system]] supporting task management. | ||
Both the Kanban board, the course of the meeting, and how the meeting itself looks like is a great opportunity for observation for the Scrum Master. It can be used to verify how the Development Team uses the Extreme Programming practices, how Solid Integration is in progress, what are the interpersonal relationships, and whether and how the work in progress is limited (limit Work in Progress). On this basis, Scrum Master can propose improvements to the Development Team that increase work productivity. | Both the Kanban board, the course of the meeting, and how the meeting itself looks like is a great opportunity for observation for the Scrum Master. It can be used to verify how the Development Team uses the Extreme Programming practices, how Solid Integration is in progress, what are the interpersonal relationships, and whether and how the work in progress is limited (limit Work in Progress). On this basis, Scrum Master can propose improvements to the Development Team that increase [[work productivity]]. | ||
In order to maintain the compact form of the fifteen-minute meeting, the Development Teams often use moderation discussion techniques. One of such techniques is the use of tokens (e.g. so-called tokens. A person [[holding]] a prop in his hand has a voice and can not interrupt it, and after the speech has finished, it gives the prop to the next person. Another technique of this type is to equip all of the Development Team members with red cards. If a person who has a voice at a given moment speaks in a direction that brings nothing to the discussion, the cards are raised and the voice is lost. | In order to maintain the compact form of the fifteen-minute meeting, the Development Teams often use moderation discussion techniques. One of such techniques is the use of tokens (e.g. so-called tokens. A person [[holding]] a prop in his hand has a voice and can not interrupt it, and after the speech has finished, it gives the prop to the next person. Another technique of this type is to equip all of the Development Team members with red cards. If a person who has a voice at a given moment speaks in a direction that brings nothing to the discussion, the cards are raised and the voice is lost. |
Revision as of 17:20, 19 March 2023
Daily standup |
---|
See also |
Daily Scrum is a meeting of the Development Team limited by time to 15 minutes taking place every day in a Sprint. The purpose of the meeting is to update the plan for the next twenty-four hours of work. During the meeting, the team inspects the remaining work and optimizes efforts to achieve the Sprint Goal. It always takes place in the same place, at the same time, to reduce the complexity of the process, and to promote good habits. It is one of the tools of Inspection and Adaptation in Scrum. It is not a statutory meeting to report progress to Master Scrum, Product Owner or anyone else.
Rules of Daily Scrum
Daily Scrum is an inspection tool because the team assesses the work done since the last Daily Scrum by analyzing how and how quickly it brings you closer to fulfilling the Sprint Goal. After this assessment, the Development Team is adapting to create a strategy that brings it closer to achieving the Sprint Goal and delivering a productive growth. This meeting is the exclusive property of the Development Team, which can be attended by other people, such as the Product Owner, but only as a listener without the right to vote. The task of Master Scrum is to make sure that the meeting does not exceed the fifteen-minute time limit, and that it takes place every day. The form of the meeting depends on the self-organizing Development Team and is optional, as long as it brings benefits for a particular team, if there are problems with finding an effective form of conducting a meeting, Master Scrum may be asked for help. Similarly, in the case of participation of outsiders, Master Scrum makes sure that they do not affect the course of the meeting.
Daily Scrum is an inspection and planning meeting and is not a place to solve problems identified during work on the Sprint Goal. If the obstacles go beyond the scope that the Real Estate Team can handle, it is the Scrum Master's job to remove them. For problems identified from the previous meeting that can be handled within the team, interested parties organize a discussion immediately after the end of the Daily Scrum.
Among some of the teams, the form of the meeting proposed in the Scrum guide, consisting in each person answering three questions:
- What did I do yesterday to get closer to the Sprint Goal?
- What will I do today to get closer to the Sprint Goal?
- Do I see obstacles in achieving the Sprint Goal?
The purpose of the meeting is to improve communication, eliminate obstacles, learn to make quick decisions, build plans and eliminate the need to organize other meetings. He also builds a social factor in a complicated creative process, which is one of the sources of Agile Management over classical methods that can not sufficiently stimulate human creativity. A strong emphasis on direct interpersonal contact, instead of using documentation, maximizes the benefits from different points of view of each person in the Development Team. Different points of view reveal the weak points of the solutions proposed by individual team members, and allows building solutions within the Complex Adaptive Systems most often affecting work in the IT industry, as well as research.
Daily verification and planning of the remaining work increases the probability of achieving the intended Sprint Goal, maximizes the value provided by the Development Team, and builds people's sense of influence on the surrounding project reality, and thus builds commitment.
Daily Scrum in practice
In order to visualize the progress of works, the Development Team often meets at the Kanban board where tasks are shown in the columns representing their state. Increasingly, the table is in electronic form, showing the status in Kanban boards being part of the electronic system supporting task management.
Both the Kanban board, the course of the meeting, and how the meeting itself looks like is a great opportunity for observation for the Scrum Master. It can be used to verify how the Development Team uses the Extreme Programming practices, how Solid Integration is in progress, what are the interpersonal relationships, and whether and how the work in progress is limited (limit Work in Progress). On this basis, Scrum Master can propose improvements to the Development Team that increase work productivity.
In order to maintain the compact form of the fifteen-minute meeting, the Development Teams often use moderation discussion techniques. One of such techniques is the use of tokens (e.g. so-called tokens. A person holding a prop in his hand has a voice and can not interrupt it, and after the speech has finished, it gives the prop to the next person. Another technique of this type is to equip all of the Development Team members with red cards. If a person who has a voice at a given moment speaks in a direction that brings nothing to the discussion, the cards are raised and the voice is lost.
References
- Stray, V. G., Lindsjørn, Y., & Sjøberg, D. I. (2013, October). Obstacles to efficient daily meetings in agile development projects: A case study. In 2013 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (pp. 95-102). IEEE.
- Augustine, S., Payne, B., Sencindiver, F., & Woodcock, S. (2005). Agile project management: steering from the edges. Communications of the ACM, 48(12), 85-89.
- Livermore, J. A. (2008). Factors that Significantly Impact the Implementation of an Agile Software Development Methodology. JSW, 3(4), 31-36.