Avienaash Shiralige

Streamline Your UAT and DevOps – Kanban Boards

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.

Use Planning Board for Product Backlog Grooming

by Avienaash Shiralige 4 Comments

In our earlier post – Improve sprint throughput we had discussed about how important it is to have stories ready for play before team picks it as part of the sprint. In short, if half-cooked stories are pushed to sprints for execution, then team will spend lot of time analysing, re-working and this eventually reduces team throughput. To address this challenge, few of my teams thought of creating a separate planning board in Jira to track planning readiness. This board was used by PO primarily to keep a tab on the backlog and also by team members during backlog grooming session.

Team was using Atlasssian Jira, I will show here how we modified the workflow and boards within Jira. Some of the issues teams had faced with the backlog not being ready were:

Insufficient scenario analysis in user stories
Lack of functional and technical impact analysis
Not much details/mocks within the story
Team doing sizing estimate during sprint planning – this was the first time team was seeing those stories and hence made sprint planning long and inefficient

Hence a workflow was designed to address above issues. Take a look at the workflow below(pasting it from Jira).

Mind the gap: Engineering Teams in 21st century, Management in 20th century

by Avienaash Shiralige 3 Comments

Quite often I get to see engineering teams – upto middle management being new to agile, are ready to give it a try. But they have real problem on hand that is – coaches asking them to:

Embrace change from business and at technical practices level
Question traditional approaches of development
Do some planning not much
Do some analysis not much – leading to analysis paralysis and list goes on…

But engineering teams have to give their management:

Long term plan
Have to commit to project estimates at the start
Accept all the scope changes keeping time almost same and goes on….

Saying “NO” to unrealistic expectations, scope and time is biggest cultural change. We see it so often. You can read more about this in my earlier post Sustainable Pace: Does Culture Play Any Role At All

One of the biggest myths in the industry or mis-understanding is: “Agile is for engineering teams”. It is engineering team who has to adopt to agile way of working to deliver sooner than they were doing earlier. It is them who have to accept changes from business. This kind of agile implementation fails miserably. Even business must be ready to accept surprises or changes from the engineering team. If engineering teams hit a roadblock and unable to deliver few stories(assuming product team was informed timely) then management should try to accept this. Business must be flexible to accept change.

Hence embracing change is both ways. Management can not be practicing traditional school of thought like “I want everything by this time” – “command-and-control behaviours” and expect their teams to be fast, agile and flexible.

Lean Product Development: Dealing with Business Emergency

by Avienaash Shiralige Leave a Comment

We all know biggest risk in the product development is building a WRONG product. There are numerous examples from history to see why some products did not see light of the day or big success.

Recently, I came across a product team which took MVP approach and built a product which saw very good initial success. But with time product was unable to keep the users engaged and convert initial success to revenue to keep it floating.

Some of the questions the team started to deliberate were:

Is this a good product idea but a targeting wrong market segment….? OR
We are in right user segment but not a right product/idea – the one which does not solve user problems completely.

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.