Is your User story really aligned to Value

Agile, the buzz word that every organisation (IT enabled; pun intended) has decided to imbibe in its working culture.  It is common to hear that success comes naturally when implementing the principles of Agile albeit on the back of sustained change. Without tearing down the word success, it is important to understand that success is often framed by a scope in an IT driven world. This scope is the single most deciding factor of 'possibly' measuring alignment of what is delivered to what was stated.

So in a simple line the formula should be :

A good scope = Group of Stated need = Great user stories = What is delivered

The pre-assumption in most scenarios where budget is owned by business is the understanding that 'real' customer requirements have been fielded, collected, analysed, bucketed into slices and than passed onto the product creation team to ensure that the end product (if there is anything known as 'the end' in a constant changing external demand driven by customers, competitive pressures, etc.) meets all the stated needs.

Agile in any of its derivatives (umbrella of methodologies), is very successful in ensuring that what is stated is actually delivered. It does this by continual re-alignment of user stories through its ceremonies and creating a well knit collaborative team that works directly with the product owner.

But, here is where a finer understanding is required. Delivering business value is directly proportional to fulfilling customer needs in time and ensuring that the product is a well knit, profitable fit, Any feature capability that is ahead of its demand curve increases marketing, sales and build cost. Too low in feature capability makes the product basic and undermines it saleability especially when it is placed in a competitive market. Getting it right, is what determines success and this what an agile methodology will help in. However, it is important to understand that it works perfectly well (defining perfection is another long article) from the point of a stated need and like written earlier, real magic happens when a product is knowingly created.

Kano model analysis is a fantastic tool that is easy to implement and ensures that any product being created or any feature upgrade to an existing product can be bucketed into:

• Delighters

• Performance Needs

• Basic Needs

It is an absolute imperative that great product design does not happen over night but at the same time it cannot be months of analysis before it is decided as both are detrimental. One relies on chance, rapidly increasing cost and the other makes sure the competitive edge is eventually lost.

As a tool, Kano analysis can ensure that every user story is aligned to any one of the buckets. It is important that every product owner understands the difference between the three bucket, subtle as they may be.

Performance needs are a no -compromise bucket and this is where most cost gets sunk in to ensure that customer satisfaction is maximised. These are the absolute top of the mind and customers would very freely speak about them. More often than not, they come with a ' need for now' mostly associated with losing a customer, an erroneous system and/or a competitive advantage.

The key to success however is to install enough delighters which create a paradigm shift in product design and allow customers to stick to the brand. There are a few examples of brands that do this, Apple and Microsoft sticking out. Ensuring, that there are enough delighters in the product ensure that there is always excitement with every feature refresh.

It is also key to know, that over a scale of time every delighters falls from delighters to performance finally settling into basic needs before moving becoming obsolete. 

A good hypothesis would be to have a build that will create:

20% Delighters+50%Performance+30%Basic = 100% aligned product

Of course, the above is a rule of the thumb and every product owner with a good mix of a collaborative team can decide the split to design or upgrade an existing product.

A good way to begin is :

Actual need= Stated need = Stated user story wherein

Actual need = Delighters + Performance needs + Basic Needs

This installs a value curve that defines stickiness and creates continual alignment to actual needs.

What kind of Product Owner are you?

Being Agile demands a symphony between business and IT at the highest level, which needs to run as a slice across all the facets that are aligned to specific customer outcomes. There is no other way, except to have a perfectly orchestrated collaborative unit that is designed to deliver success not as a ' one single burst' but one that allows incremental development. This symphony creates continual value for the end customer as well as allowing teams to implement Kaizen.

However, being Agile is driven more by behavior modeling rather than just implementing a methodology of check boxes. It needs to integrate at the deepest level to ensure that there is continuum in aligned delivery and that requires people to integrate together as a feature team working together with a servant leadership approach. Anything other than this only creates a working facade which delivers, but never really aligns itself to generating teams that are charged to deliver business value.

For this to happen the acceptance of change of working together as a team extends beyond co-location and needs to be fashioned by roles that exist within any Agile framework. One of the key roles is that of a Product Owner.

On a measured scale of time, and given the scenarios a product owner can strongly influence  the acceptance rate of being agile. He/she can be a strong trigger point and understanding the dynamics of a chosen leadership style at different points of time can help a smoother transition.

Its important to understand that there is no single style of leadership and real leaders adopt a flux model that freely allows them to create an environment which breeds change and continual improvement enabling collaborative self organising teams to excel.

Let us look at the three leadership styles from a singular point of view and its impact on acceptance of change

1. Aggressive Leadership : This leadership is characterized by a highly regimented and directive based approach that is highly focused on accomplishing specific tasks. While the acceptance rate is high, this is normally associated with a lot of distrust and dis-satisfaction among the collaborative teams. The teams quickly accept but fragment over time to dissolve the acceptance rate of change as it naturally harbours political agendas to match leadership behaviour.

2. Passive Leadership : This is usually characterized by a leader wanting to please and create an environment that is driven by lose decision making; often never enough and teams usually command outcomes. The acceptance rate of change is very slow in the beginning but it usually rationalises itself to have a balanced outcomes especially when deadlines are attached. This type of leadership usually blends itself well to organisations with a slow pace of change. And normally never does one stitch high performing teams as they are 'outcome attached' but not driven.

3. Assertive leadership : This is most preferred form to achieve rapid change that is aligned and deliver frequent quick outcomes. Teams under this leadership are often characterized by high performance, continuously evolving in collaboration, flexible and very outcome driven. However, no human behaviour is a straight line and this style requires carefully chosen actions that 'dictate' assertiveness and not aggression. The line is very thin and often blurred, but not something that cannot be achieved. It often requires proper coaching and mindfulness to ensure the skill is developed.

Collaborative teams are great but they get better if they are given the right environment to breed success to which a product owner can bring immense value.

Understanding the SoS: Scrum of Scrums

The Scrum of Scrums is an essential piece for ensuring highly complex, interdependent projects within a large Agile program remain connected. This is a critical enabling structure that can be scaled up or down depending on the demand that each feature team has within the conglomerate structure (I prefer this to the word ‘program’ as true value is always evolving and needs constant re-alignment). Whilst, there are enough ways to create an evolving structure, I believe the following visual columns usually work well and I have found them to be very useful.

Feature Team: The boring way is to have a number tagged purely for the purpose of identifying work against each of the teams, however a more interesting way is to have a theme around which teams choose characters that they closely associate with. Establishing avatars within the team makes it more vivid, enrapturing, colourful and most importantly visual enough for quick traceability in a busy board.

Business Outcome: I specifically advocate this column as it is important to remember that as a team only the highest value item should be delivered from the product backlog. The user stories in a product backlog should be aligned to a business outcome and sometimes these are treated being equivalent to a super-epic level. Whilst a set of teams can define their working structure, it’s important to have business outcomes that need to be fulfilled at least over the next two release cycles. This ensures that the team is productive enough to constantly deliver and user stories are available to be taken into the sprint planning sessions. Its important to remember that the business outcome are continually evolving and new outcomes can get established over time. I sometimes like to link them to mission statements as they become quantifiable and allow metrics to be evolved that allow ‘measure of success’ for the outcomes.

Release Backlog: In complex programs this is a must. The Release backlog only consists of those items that are being worked on within the feature teams. Its important to note that it is possible for ‘teams’ to work on an outcome or have ‘a team’ working on an outcome.  Either way, this column helps as teams work only on high value items as well as ensuring that teams don’t work on conflicting outcomes that may delay releases. Of course, this is not the only reason for delay in releases.  It’s important to understand that release preparation is all together another detail and is handled in different ways.

 In transition: These are specific user stories that are within the ‘refinement/grooming’ phase. It’s important to understand that they need to be prioritized and should ideally be the next block of work that would potentially be committed. Do note that this does not mean that they cannot be swapped out. Urgency and demand are the two essential pillars that guides presence of a user story in the transition column. The importance of putting them ensures that teams on a SoS have a visual understanding on the pipeline of work and can be abreast of interdependency between user stories so that sprints in turn releases are not impacted.

Ready: This column indicates the user stories that are ready for the committed sprint and should limit itself to the current sprint. Its important that the definition of ‘Ready’ is clearly understood by all the feature teams. The I.N.V.E.S.T model is a great way to ensure that a set of user stories are ready and alignment is common.

Doing: More often than not, this column is often split further as teams often like to detail what stage each user story in. The most common is Build and Test. Its important to note that doing is a critical stage as it is actually the one that measures cycle time (the definition is not equivalent to time) of story points (or any other equivalent method) between the ready and done stages. Its important that all user stories that are within the ready state (committed) move through the sprint to the done state. Ideally a team has understood its capacity well to deliver and has established a trend of its cadence. In the early stages, new teams may over or under commit. Its important to note that good teams establish value based cadence and understand the importance of releases.  More frequent the releases, the more the opportunity to take feedback and improvise.

Done: There are as many connotations to the definition of done as there are variants. Its important that teams hold closely to the definition of done. The simplest way to measure of course is to have an affirmative agreement from the product owner on completeness of the user story (usually measured via. the agreed and established acceptance criteria). This should include testing. The Definition of Done provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design. Apart from this the definition of Done, limits the cost of rework once a feature has been accepted as "done". Having an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer or product owner. This would list the user stories that were committed earlier as part of the sprint planning.

Ready for Release: The simplest alignment to this is the MVP. Complex programs often require interdependent stories to be complete before a successful release or each capability/feature set may be a release by itself. It’s important that interdependent teams are synergised enough to ensure that the release truly represents the value the customer is looking for. More frequent the releases the better and that should be the motto for any agile team.

Impediments: This is the ‘missing’ column. If it is ‘visually critical’ than making it present on a board is important as a separate column. Honestly, the importance is to get action on an impediment and just laying a red flag as a display or as a mark (bold enough to be seen) is enough to get action. It’s important that teams discuss and speak around the impediment.

Like everything Agile, keep evolving because perfection never really existed and good is relative. Visual mechanisms enable action but only if teams action themselves and ensure that they speak around specificity. Without action any visual board becomes stale quickly and devolves the traction in the team.