Principles behind the Agile Manifesto

12 Principals of agile

• Welcome changing requirements, even late in  development. Agile processes harness change for
  the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

How to get the end dates in an #Agile project – Practical approach to story point estimation!

Traditionally the estimates are given in days, months or person-hours with a probable end date to the project and these estimates don’t include time in meetings, email, and other non-project related activities all of this considered to be as a “PROJECT BUFFER-TIME.”

Traditionally how it happens

Estimates for our project

• One month for design and architecture
• Four months for development
• One month for testing
• 15 days of buffer time

Scenario 1 – your estimation of design is off by 2 weeks, what do you do?

You have already given the date of final deliverable. Usually, dates have an emotional attachment to them, and relative estimation removes the emotional attachment of the end date.

Scenario 2 – During the start of the project you don’t know much of the requirements to start, possibility of wrong estimations are higher.

The cone of uncertainty defines – during the start of the project the probability of estimates going wrong are very high, due to high degree of uncertainty.

“Story point represents the amount of effort required to implement a user story in a product backlog”

So while defining a story point to a particular user story in the product backlog one would consider the following factors

1. Risk
2. Complexity ( which governs the effort)
3. Uncertainty of the requirement ( which involves dependencies and doubts

So, if story points should estimate of how long it will take to develop a user story all the factors such as the risk and complexity should be factored into effort involved in implementing it. Story points represent time. This has to be so because time is what our bosses, clients and customers care about. They only care about complexity to the extent it influences the amount of time something will take.

What agile manifesto advocates is “Estimates may not be accurate, but they need to be consistent, the sprint velocity would correct the inaccuracy of the estimates”   The idea to compare your last given estimates with the next estimates time and again in order to reach consistency in your estimates.

Assumptions to be made

• One of the most important considerations that need to be made while defining the story point is assuming the ideal day, where everything works as per the plan, no sick day, no one interrupts etc.
• No individual task should be more than 16 hours ( you can decide a number to define based on your project
• Assuming that your team size is constant and team understands their roles

Identification of the base/reference story

Breaking of the user stories until you reach to a small story which cannot be further broken. Making this is a base story or the reference story based on which you would relatively estimate the product backlog. This is important to create the initial product backlog.

Tuning the base/reference story

After the team has created the initial product backlog, pick one of those stories that are a good representation of an “average” story from that list few user stories and do a relative mapping to the story against the average story and assigning a story point to this reference story and realign the product backlog with the new number. The product backlog grooming is a continuous process which happens throughout the entire project.

Techniques of estimating

There are various techniques for assigning user story points to a user story.  Common estimating methods include t-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, etc.)

Agile emphasises that the story point estimation should happen at the story level not at the task level

The estimation should not happen at task level but at the user story level as some of the tasks might not be required as we come closer to the final delivery of the user story or even the user story may get dropped during the sprint planning meeting. One of the key things to remember during the estimation is working with the product owner and identifying the user story which is the most granular part of the product backlog which means it is simply small or needs to be split. As a part of the sprint meeting the team needs to define two key points would the team able to take this user story in the current sprint or this need to be broken into smaller deliverable user stories.

Learn from past estimates

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools tracks story points, which makes reflecting on and re-calibrating estimates a lot easier. For example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You’ll get better and better with time.

Global Regulatory and Tax Accounting- Point Solution

A point solution which has limited adoption time and that can be integrated with the downstream and upstream application in the business. Instead of created a platform or a product for all the global regulatory changes made by various Global regulators like the IRS, FINRA, SEC, FCA, BASEL, etc. creating a point solution which can be then customized based on the customer technology, business requirements and sophistication of the users and technical capabilities within the organisation

End to End Solution

Advantages of having point solution over platform/products

1. One size does not fit all
2. Customer technology culture – Some companies can handle outsourced services and are not interested in customizing platforms. Some IT departments, even in the largest of companies, are more focused on user experience than control and support departments in their efforts match their innovative processes
3. Easy to get going and straightforward – client can make a decision whether to outsource the entire element to a service provider. Also, reduces the technology complexity when using multiple technologies for the same line of business the diagnosis of the problem is always challenging
4. Low cost compared to the big enterprise platforms, as this may minimize the data complexity as each client tool would have its database with its structure and integrating these databases is hard
5. The point solutions can be converted to enterprise platforms through M&A.

Key Success Indicators

1. Regulatory risk reduction
2. Cost Optimization through automated workflows
3. Business Change adaptability with minimum business impact
4. Robust control framework