Skip to main content

Retrospective Meetings By:Namrata Parik

This article talks about the least important meeting in a Sprint, the retrospective meeting, at  least as considered by the business and sometimes also by the developers.
It is often considered to be a waste of time and given the least priority, and sometimes even omitted if there are time constraints.
In fact it is the most important meeting but does not show any immediate business value.
Talking about my own experience, we were newly into the project and the geek in the team was not getting enough technical tasks to devour, resulting in not so good documentations by him and his general disinterest in the team.
This was discussed in the retrospective and his problem was faced, assessed and solved within a span of two weeks (a single Sprint), and he was given enough tasks to fulfill his coding appetite, resulting in better output by the entire team.
Talking about retrospective techniques, the most effective way to conduct a retrospective is the Timeline Review.
The team starts on a whiteboard where the time line is drawn as shown below and the team discusses: What went well, what did not go well and what should we keep doing.
Image Source: Google Images
The business should not be a part of this meeting as the team should feel comfortable enough to discuss their concerns. The aim for a retrospective should be more to get the team to come up with their issues.
Any thing that went well deserves a pat on our(team’s) shoulders, and it becomes the responsibility of the scrum master to make sure the grievances are addressed.
While reading the graph we should follow a sinusoidal pattern which means we get an idea on what went well and what did not go well at a particular time in the Sprint. This would help us understand if at any point in a sprint, any team member is facing issues due to other dependencies.
Image Source: Google Images
For Example: In my team we needed data on the go for some ongoing tasks, the other team sometimes failed to give it on time resulting in non completion of the task and so we decided that if we do not get the inputs before the start of the sprint we will take the task which we planned for the first half of the sprint. This was a small issue which had a simple fix but could be addressed only after the team discussed it in the retrospective, or else it would keep on affecting the team's velocity.
Keep on noting down the feedback from the team members.
Once the team is matured the time of the retrospective should go down but it is supposed to be a dedicated meeting until that level of maturity is achieved.
Now, since the team is matured it has more knowledge about the process and flow. They are now in a better state to suggest changes in the project flow.
Other methods can be taken up once the team is reaches this point, one effective method is ‘Starfish’
Image Source: Google Images

Comments

Popular posts from this blog

User Story In Agile Scrum - By Ankur Mistry

In this article, we will learn what User Story is and how to write one. User Story plays a major role here. It is the part of the Agile process where instead of writing comprehensive requirements, we write a short description of a feature. As the  Agile Manifesto  says 'Working Software' Over 'Comprehensive Documents'. What is User Story? User Story is a short and simple description of the feature or requirements of the project. Generally, user stories are written on sticky notes or index cards as a user or role-based perspective. User Story Template As a < type of user or role >, I want < some goal > so that < some reason >. The template identifies 3 questions - "Who", "What", and "Why". If the team doesn't know these three answers, it means they don't understand the story, and if they don't understand the story, then it's difficult to split it well.   Reference:https://mazoea.wordpres

Visual Studio Team Services - Agile - Scrum Project Management Tools

Before starting this article let's understand what is Agile and Scrum.  What is Agile Agile is a  Method  of project management that is characterized by dividing module in to tasks and t asks into short phases of work and frequent reassessment and adaptation of plans. In other words, Agile is a Time Boxed incremental software development method.  What is Scrum Scrum is an incremental agile software development framework  (Agile Framework).   Agile Scrum Process in Short. Product Backlog:  A product owner creates a customer’s wish list and prioritized it and create backlog, called Product Backlog. Sprint Planning:  In this meeting team select small part or module from the Top Priority Wish List of Product Backlog and prepare a small task list. Setting Capacity and Sprint:  Team has to deliver the tasks in 2 weeks or 4 weeks sprint, here Scrum Master bind tasks with Time and User. Scrum Master’s role:  Is to make sure team focused on its goal. End of the sprint:  

The Burn Up Charts In Scrum By: Namrata Parik

I would like to propose a less-taken path in my maiden article to track the progress in scrum. We usually do it using the burn down chart which is relatively easier to understand as compared to the burn up chart. These charts help the team and stakeholders to see and track the progress at any point in the release process or sprint. Burn-down chart provides us the information showing the progress based on the remaining hours or story points from top to bottom. (The burn-down chart can be plotted using story points, task count or the remaining effort) This chart is a plot of expected remaining and actual remaining, this is the most used chart in scrum and since it has only two lines it is considered to be a simple chart. It does not cover the scope creep. So sometimes what might look like ‘no work ‘ done by the team may actually be a result of scope creep. The chart below reflects that the team has not done any progress in Sprint 5 and 6 as the story points remain the same. Image