{"id":6966,"date":"2022-11-16T14:01:57","date_gmt":"2022-11-16T13:01:57","guid":{"rendered":"http:\/\/blog.bart.sk\/en\/?p=6966"},"modified":"2022-11-29T14:36:06","modified_gmt":"2022-11-29T13:36:06","slug":"types-scrum-meetings-tricks-make-better","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/types-scrum-meetings-tricks-make-better\/","title":{"rendered":"Types of Scrum meetings and tricks to make them better"},"content":{"rendered":"<p><b>Scrum&#8217;s all about teamwork. And without the team meeting (online or offline), making decisions together, evaluating as well as praising, it simply won&#8217;t work. That&#8217;s why the core of the Scrum methodology is a series of recurring events. Years of practice have taught us how to make the most of each of them. It&#8217;s mainly about using the right tools and asking the right questions.<\/b><\/p>\n<h2><b>An electrician can also come to planning<\/b><\/h2>\n<p><b>The first of the meetings is sprint planning.<\/b><span style=\"font-weight: 400;\"> The entire team, including the Scrum Master, participates and it lasts a maximum of 8 hours in a monthly sprint. On our projects, it takes somewhere between 2 and 4 hours. <\/span><b>The purpose of this meeting is to listen to the Product Owner and define the sprint goal together.<\/b><span style=\"font-weight: 400;\"> Subsequently, the planning goes into the hands of the development team, who decides what they&#8217;re able to deliver as part of the sprint. The result of the event is a work plan for the next sprint.<\/span><\/p>\n<p><b>The team can invite other people to planning to help them understand the context needed to achieve the sprint goals and provide advice.<\/b><span style=\"font-weight: 400;\"> Anyone who understands the project and what it&#8217;s supposed to bring to the client \u2013 whether it is an accountant, an architect or an electrician \u2013 can be invited to the meeting.<\/span><\/p>\n<p><b>When planning, we like to use the so-called User stories, into which each function within the sprint is divided.<\/b><span style=\"font-weight: 400;\"> When creating user stories, we use the WHO\/WHAT\/WHY tool. This helps us to clearly define the criteria that ultimately lead to a successful completion of the task.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A user story may look like this: <\/span><i><span style=\"font-weight: 400;\">As a teacher (who), I want the Edupage application to display all news on the website (what), so that parents and students are regularly informed (why).<\/span><\/i><\/p>\n<h2><b>Daily stand up for a successful sprint to the finish<\/b><\/h2>\n<p><b>The result of each planned sprint is to meet the set sprint goal and increase the value for the customer.<\/b><span style=\"font-weight: 400;\"> It&#8217;s good to visualize its progress through a suitable tool \u2013 in bart, we use Gitlab, Jira, AzureDevOps or a plain whiteboard.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Each team member should have their tasks updated on a daily basis. This is important so that everyone on the team knows what the status of the individual tasks is and to maintain transparency.\u00a0<\/span><\/p>\n<p><b>The team reminds itself daily of fulfilling the sprint goal at stand-up (daily) meetings.<\/b><span style=\"font-weight: 400;\"> These take a maximum of 15 minutes. There&#8217;s also room for mutual consultation in case of issues and suggestions for improvement.\u00a0<\/span><\/p>\n<p><b>The most common stand-up practice is answering 3 questions:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">What did I do yesterday?<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">What am I going to do today?<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Do I have any problems that will affect the sprint goal?<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Stand-up, however, shouldn&#8217;t only fulfill the task of vocalising the status, but also answer the question whether we&#8217;re approaching the goal of the sprint, and if not, how we need to reschedule the work between people.<\/span><\/p>\n<p><b>Development in a team also means that even if tasks of one team member are finished, but tasks of other team members are not, even this one member, who already has &#8220;done their job&#8221;, continues to work and tries to help the colleagues.<\/b><span style=\"font-weight: 400;\"> Therefore, it isn&#8217;t uncommon for tasks to be rescheduled during stand-ups and they&#8217;re distributed among people based on the current situation. We follow the rule that it&#8217;s always better to have 3 out of 5 scheduled things delivered than to have all 5 in progress and none completed.\u00a0<\/span><\/p>\n<h2><b>Evaluation also requires speaking skills<\/b><\/h2>\n<p><b>At the end of the sprint, during its evaluation (sprint review), the finished tasks are presented to the client but also to everyone who is involved in the project and was invited to the meeting.<\/b><span style=\"font-weight: 400;\"> So it includes the product owner, investors, suppliers, the client himself or even a sample of customers sent to the meeting by the client. The evaluation takes a maximum of 4 hours.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">At this meeting, the team receives feedback and at the same time, it&#8217;s assessed how the sprint goal has been met, new features are approved, additional requirements are defined and finished parts are presented.<\/span><b> Here the client directly sees the increase in value of the product. This is the only meeting where the team can meet with the client and see a &#8220;live&#8221; response to the product they are developing.<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Knowing how to present yourselves needs a certain dose of extroversion and speaking skills. If a member lacks these characteristics, they may ask a more eloquent colleague to present their task.<\/span><\/p>\n<h2><b>Retrospective to express every opinion<\/b><\/h2>\n<p><b>The last regular meeting is a maximum of 3-hours-long retrospective.<\/b><span style=\"font-weight: 400;\"> It can take many forms, but its intention is always the same \u2013 to allow each team member to express their opinion and say what&#8217;s good and what could be changed\/improved in the next sprint. <\/span><b>At the same time, it&#8217;s about self-reflection, praise among the team members and mutual motivation.<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The content of the retrospective isn&#8217;t discussed across teams, it&#8217;s an internal meeting within the team. The important thing is that no one blames anyone during the retrospective. <\/span><b>If something goes wrong, the whole team takes responsibility for it and together they look for opportunities for improvement.<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A retrospective should always end positively. Even the negative things that are discussed here are necessary to bring about change that is positive in the long term.<\/span><\/p>\n<p><b>The entire team participates in the retrospective and everyone has the space to bring suggestions for improvements.<\/b><span style=\"font-weight: 400;\"> However, we shouldn\u2019t forget the more introverted members, who probably won&#8217;t be comfortable talking out loud, and therefore it&#8217;s advisable to consider using some of the online forms of a retrospective, for example retrotool.io. Here it&#8217;s possible to create &#8220;bulletin boards&#8221; where members can write their opinions anonymously.<\/span><\/p>\n<p><b>Types of bulletin boards that we like to use and rotate on a regular basis so that the retrospective is not monotonous:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Mad | Sad | Glad<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Liked | Learned | Lacked<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Start | Stop | Continue<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Fast | Furious | Fearful | Looking Forward<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Kudos | Went well | Could be improved<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">What went well | What could be improved<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Superpowers | Kryptonite<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Strengths | Weaknesses | Opportunities | Threats<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Drop | Add | Keep | Improve<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Pride &amp; Joy | Personal improvements | Team improvements<\/span><\/li>\n<\/ul>\n<p><b>Finally, all proposals for changes that are mentioned during a retrospective are written down in the form of action items and gradually implemented.<\/b><span style=\"font-weight: 400;\"> We register them in Confluence, Gitlab or directly in the online retrospective tool. At the beginning of each subsequent team retrospective at the latest, the incorporation of action items is checked.<\/span><\/p>\n<h2><b>None of them are the best &#8211; or are they all the best?<\/b><\/h2>\n<p><b>It&#8217;s very important to carry out all 4 meetings as part of the development. Each of them is the most important one for a different team member.<\/b><span style=\"font-weight: 400;\"> The product owner needs to explain their requirements and make sure that the team understands them. The client, on the other hand, wants to hear the results and therefore the evaluation is the most decisive for them. The development team must consult daily and share information about progress, so for them, stand-up is necessary. Well, the scrum master probably considers the retrospective to be the most important one, where they can motivate people to achieve the best results possible.<\/span><\/p>\n<p><b>Properly set and effectively implemented meetings form solid pillars on which every Scrum development is based. We can&#8217;t even imagine our work without them.<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"Scrum&#8217;s all about teamwork. And without the team meeting (online or offline), making decisions together, evaluating as well&hellip;","protected":false},"author":9,"featured_media":6971,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","csco_display_header_overlay":false,"csco_singular_sidebar":"","csco_page_header_type":""},"categories":[335],"tags":[339,341,340,276],"_links":{"self":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/6966"}],"collection":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/comments?post=6966"}],"version-history":[{"count":1,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/6966\/revisions"}],"predecessor-version":[{"id":6967,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/6966\/revisions\/6967"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media\/6971"}],"wp:attachment":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media?parent=6966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/categories?post=6966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/tags?post=6966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}