Contact Us
×

Tag: course on agile business analysis

The Charm Of User Stories

Posted on by Imarticus Learning

Beauty lies in the eyes of the beholder. The simplicity of a user story allows for this approach becoming the fundamental artefact in your project armoury. Let us understand two simple concepts in user stories which highlight how a user story operates and the INVEST acronym holding it together. These two simple techniques of product backlog formulating improves the quality of the product, communication of value to the user and rests wholly on the user.
Let us move to the 3C’s principle. The 3Cs approach components are:

  • Card:

Aptly named it forms the written-down text of the user story and is an open-invite to the next logical step of conversation. This concept accepts that like in Scrum the Product Backlog items are imperfect and invites the team to discuss, discover and diffuse iterational conflicts. At this stage of discovery, the elements of collaboration and communication are crucial to refinement.
It addresses the why, what and who in the user story. The format asks leading questions to discover the role, benefit and action required. Since the team is cross-functional, the questions are both important, and the user card is developed with an actual persona in mind while addressing the benefit and assigning it to the business-goal benefits.

  • Conversation:

Normally all conversations are face-offs and moderated by the Product Owner. A collaborative discussion of all stakeholders ensues. This is the phase of the actual value of the user-story getting written and reflects the commonly accepted terms shared by all members before recording ‘Doneness’. Ideally, it also includes the Acceptance tests and methodology to be followed, so a shared understanding is recorded.

  • Confirmation:

The PO firstly confirms ‘done’, and the team checks the ‘doneness’ and its alignment and common definition of ‘done’ in writing of the user story.
Next, we move to INVEST and what it stands for.

  • I means Independent:

This lets the team know that this user story is independently solvable and implementable immaterial of other user stories and can be broken into technical dependency as often as required using refactoring principles.

  • N means Negotiable:

This is an open-ended evolving iterative story and is flexible and yet to be attributed to technical specifications. The DevOps team takes the final call on technical implementation.

  • V means Valuable:

Here is the why question. The alignment of business goals to each user story is vital. However, it does not suggest that every user-story must evolve into a marketable product. More than the user view the business goal is paramount.

  • E means Estimable:

In this head, it calls on the team to be Agile and approximate the work-complexity, effort and time required to build a potential bearing product. Final values will be based on consensual approximations.

  • S means Small:

In this stage, the item should qualify as small functional increment achievable in a single Sprint. As it gets to the top of the Backlog list, it achieves its maximum size due to ongoing collaborations.

  • T means Testable:

This phase deals with the common definition of the team understanding on verification and testing procedures acceptable for a ‘done’. If there is a common consensus that the ‘done’ can be verified in a particular procedural manner the ‘doneness’ being achieved in one Sprint implies the product is testable.
The INVEST set of rules is applied to all items on the Backlog list even when user stories are to be written yet.
In conclusion, the Agile user story is simple to learn, and the charm of the user story lies in its team-collaborated iterations and evolution.

Three Questions To Determine If An Organization Is Agile

Posted on by Imarticus Learning

Being Agile is a continuous process and a way of thing. One should never expect 100% Agility. Just as every sport is larger than its practitioners no matter how famous they are. The same applies to Agility! There will be areas of improvement, techniques of excellence and some areas of total failure. Just to give a fair idea of Agile progress in an organisation, the three important questions one must ask are as below.
Q1: How often are products fully integrated by the teams?
This question is meant to assess the team functionality and hence organisational Agility from a customer’s point of view. While many people ask how many releases and how frequently releases happen, this may not be a true index value. This is because the question of releases and frequency of releases both depend on the client needs.
A persistently demanding client will have more releases and frequently so with no real way to compare the performance of products. Going a level higher the integration frequency of products is a better index since it does indicate how often projects are released and how quickly. The capacity for being Agile especially in cross-functional teams is a good way to judge the full capacity of the organisation to release marketable products.
Q 2: How would you handle critical issues that cause the timelines or planning to go awry and make achieving them impossible?
This question is directed at measuring leadership Agile commitment. The crisis response is a true indicator of Agility. Critical phases are times when Agile principles need to be put into practice. If the response is that during crisis stages Agile is not employed for resolutions, then the organisation has no commitment to Agility which remains a mere unpracticed fad.
Q 3: Why is your Scrum Master or PO the best?
This question is meant to figure out the dysfunctional areas in organisational Agility. Taking such opinions will assess WHY someone thinks the SM or PO is the best. Many giveaways are available in their opinions. Is the SM dedicated, full-time or distributes his team-time?  Most answers will let you know if the SM/PO is effective and meets the team’s needs. You may also hear of SMs who bark orders and tell people how bad their Scrum values are. This is especially true of past Project Managers in the Scrum Master role. This effectively lets the cat out of the bag. Scrum is to be practised at all times and even in personal life. However, when a person is still a project Manager and titled SM, he is more prone to behave as a PM.
Similarly, opinions about the PO also reflect the team Agility. How can a great PO do the real job and still be a good PO without affecting his/her job? A PO needs 100% clarity of project, is able to stay and explain iterations to the team and contribute to a performing Scrum Agile team. If the PO is just attending the meets, then iterations can lead to missed calls, poor clarity and a host of negative Agility scorers.
In conclusion, you may have to understand why these questions are asked and rephrase them. However, 3 questions are not enough to get a complete picture. The pointers in the answers are a good start to understanding company values, team functioning, effective leadership being present and state of Agility. Base your assessment and opinion on these answers.