Agile Buddha - Page 21 of 23 - Demystifying Agile, Getting to its Core

Is “Faster, Cheaper” Enough? The New Rules of Service Differentiation with Kano Model

Service companies offerings and messages often says “Faster Time to Market” or “Reduce your Cost of Development“…. Do you think it is a game changer NOW? I would agree if it was couple of years back. But is it still? Applying Kano analysis here could reveal few thoughts.

For those not familiar with the Kano Analysis, there are three types of features or needs. This is more easily depicted in below picture:

[Read more…] about Is “Faster, Cheaper” Enough? The New Rules of Service Differentiation with Kano Model

User Stories: Lack of Big Picture Leads to Blind Man Product

by Avienaash Shiralige 5 Comments

One of the Scrum values is “Focus”. It can make or mar a product. It brings direction to the development of a product – from start to finish; and is the back-bone of an effective business strategy.

Having said that, overdo it and the tables are turned. Fret too much over ‘focus’ and what could have been a blessing may become your curse.

Here’s why:

Analyse this picture. Highly focused teams (teams seeing project from sprint to sprint) may well become blind to the big picture perspective.

Scrum Team Dependency on User Experience/Wireframes

by Avienaash Shiralige 7 Comments

Dependency management is a key aspect in Scrum. Dependencies between Scrum team members, between User Stories, between core and extended team, between team and product owner – all have an impact on the efficiency and effectiveness of the team.

I often see Scrum teams having dependencies on User Experience/Web Developers. This is because PO has defined requirements for new sprint, and UI/Web-Developers who are part of development scrum team start working on this now. Wire-frames are yet to be created as per these requirements.

Scrum Product Owner Has to Kiss Lot of Frogs to Find a Prince

by Avienaash Shiralige 3 Comments

I, am going to draw an interesting parallel – between a fairy tale princess and a Scrum Product Owner (PO). Just as the fairy tale princess may need to kiss many frogs before she finds her prince charming; a Scrum Product Owner has to do a lot of de-cluttering of backlog to identify features that will make his product successful.

Innovations go through several attempts before light bulb moments strike. Steve Jobs said, “Innovation is not about saying yes to everything, it’s about saying NO to all but the most crucial features.”

Backlog grooming and it’s prioritization directs the team and keeps it focused. Certainly, there are different aspects you need to consider for prioritization like uncertainty, risk, dependencies, effort, releasability and value etc.

How to Use Sprint Burndown Chart in Daily Stand-up and Sprint Retrospective

by Avienaash Shiralige 1 Comment

Sprint Burndown chart and Daily Stand-up help Scrum teams in Self-Organisation. Never use Sprint burndown chart in sprint review. Sprint Burndown is inward facing, i.e it is for Scrum Team.

This chart summarise overall how team is doing? Every impediment, every challenge team faced, colloboration issues etc all get summarised in this chart. Teams need to update the tasks with time remaining in hours to get this chart. Scrum Master prints and analyses this updated Burndown before daily stand-up and brings it to the meeting.