South Gujarat Agile Scrum Community

Scrum addresses the software development where the requirements are frozen before the sprint starts, but what about the teams which work on dynamic requirements which can come at any time? For example in a team which works on technical tickets, these tickets may come at anytime and hence the sprint cannot be decided, estimation cannot be done and the velocity cannot be calculated. Kanban is the solution to all this. Started in Toyota, Japan this was introduced to increase the productivity of the factory. ‘KANBAN’ in Japenese, means a visual signal. Kanban was later used as an effective method in agile software development and it can be implemented in teams where requirements are not certain. The work items in this approach, are put on a board where each team members can access and update their work. The team can have a physical or virtual Kanban board. Colocated teams prefer to have a physical board. The basic function of the Kanban board is that the team can visualize thei

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 s

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