Scrum

Collaborative Daily Scrum – Alternate to 3 Questions Based Daily Scrum

Scrum is inspired by Rugby Scrum. The entire development team works collaboratively towards one Sprint Goal.

Pretty obvious but still spelling out – Rugby Scrum can never be played individually in a team.

Working solo or without collaboration (read pair programming, swarming or mob-programming) is not even a choice in Scrum/XP.

With this background in mind, let’s focus on Daily Scrum.

Daily Scrum

Daily Scrum is a sprint planning in small. You replan the sprint every day. – James Coplien

A lot of Scrum teams use 3 questions based daily scrum. On the surface, it looks good but it comes with some inherent problems:

Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige 4 Comments

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.

Scrum Backlog: Epic, User Story, Acceptance Criteria

by Avienaash Shiralige 3 Comments

Often, I get to hear questions about level of details that need to go in the product backlog stories. How detailed should be the acceptance criteria? or how small the story should be? We all know stories matures with time. I really like this post on user story life-cycle. Please take time to read this. Let’s consider an example now.

User Story example: As a Project Owner(PO), I should be able to transfer complete project ownership to my connection, with my role remaining to be just a project creator(author) after transfer.

Note: At the first sight, it is tough to say whether this is a story or an epic. When this story comes up in backlog grooming meeting, teams might completely miss the magnitude of such stories. Hence, as the product becomes bigger it is wise to start detailing stories by adding acceptance criteria earlier in grooming meetings itself. Impact of every new story gets wider as product becomes bigger which often gets missed by the team.

Webinar: How to Deal with Emergencies in a Lean/Scrum Team

by Avienaash Shiralige Leave a Comment

Every Agile team has to deal with different emergencies next to their regular work. Every team dream of achieving sustainable pace comes with nightmares of production emergencies/defects, support and maintenance tasks within a sprint which takes focus completely off the sprint goals. The goal of this webinar is to see different approaches team can take to absorb a reasonable amount of uncertainty, striking balance between robustness and speed within the sprint.

Also we will discuss about how to deal with “Pivot” in lean product development. In this state, product has to go through a course correction in terms of vision, market segment and features. This is almost an emergency on business side. In webinar, we will see how engineering teams need to do course correction in their approach too.

Audience will learn:

How to plan for production emergencies during a sprint
How to apply strategic and tactical thinking to handle changes
How engineering team needs to deal with development when product is in Pivot

If this sounds interesting to you, please register for the webinar here. Do share with others too!

Webinar Timings: Wed, May 13, 2015 9:30 PM – 10:30 PM IST

Agile Thinking : Stop Starting, Start Finishing

by ShriKant Vashishtha 13 Comments

Limiting “Work in Process” (WIP) items is one of key ideas of Kanban. A natural outcome of it, inherently coming from Lean philosophy is to stop starting and start finishing.

By having too many work in process items, it looks like everybody is busy but there is no functional outcome for the end user. So, instead, it’s important to work towards completing the user-story.

From the outset it looks like, “Stop starting, start finishing” philosophy is limited to Lean and Kanban world. Scrum world is either doing it well or doesn’t need it. Right?

Wrong!!!

Let’s take a look at a typical Scrum standup.