Ever wondered how to write foolproof acceptance criteria? Or even wondered what a business analyst can do to ensure that requirements are testable? Acceptance criteria define the minimum requirements the solution must meet. A business analyst plays a key role in defining the tests around it. The acceptance tests can be at various levels of requirements detail. Starting from high-level requirements to detailed requirements. Let’s take a look at common challenges involved in this part of the world, along with a few ideas to overcome those.
A business event is something that happens, and when it happens it causes a pre-planned response by the business, or as we shall call it here, “the work”. One category of business events are the things that happen inside an adjacent system. The work is made aware that the business event has happened because each happening produces a flow of data to the work. A business event is a significant happening – it is not just a mouse click. It is often a request for a service that your business provides, and the outcome is the provision of the service or product.
Writing functional specifications as a business analyst (BA) in an agile ecosystem is a challenge of a different kind. You no longer have the luxury of time (unlike bigger waterfall projects). You no longer can be sure with a specification version as the final document (because of the iterative philosophy). You are not sure how comprehensive the functional specification should be (Agile manifesto: working software over comprehensive documentation).
I could not help but observe in awe the agility of this monstrous wing. My mind could not stop analyzing how an airplanes uses the agility of its wings to control the pressure of the air that flows through them and manipulates the latter to enable it to navigate its journey into the skies. The aeroplane does not change the physical or scientific formation of the air, but it changes its wings to adapt to this natural phenomenon. How intriguing. Adaption. Agility.
Good news is that the adoption of an agile approach is increasing with more and more projects being successful. As a business analyst / project management professional, it is important to understand how success is measured for Agile projects? What are the key performance indicators and metrics?
In this article, I am going to list down the top metrics for measuring the success of Agile projects/approaches.
An agile organization is characterized by having a comprehensive portfolio of optimized business process and business capability maps grouped by their role in value creation for the customers and support of the business strategy. These maps are linked to all the other disciplines such as finance, governance, resource management, talent management, and customer experience. Thus, Corporate IP can be securely delivered to the point of need.
As much as we like to think we are now in a dynamic and agile world, most delivery initiatives are still some shades of agile and all shades of waterfall. These initiatives could have adopted an agile outlook and naming convention, but the businesses they support are often still predominantly waterfall – going from one clearly defined task to another until realizing value. Think for example, order to cash, just in time logistics etc.
The transition from Waterfall to Agile is never easy – especially for a business analyst who must go through this journey. This document has come about because of this challenge and as an attempt to present a practical guide of how to effectively transition over as a business analyst, and where are these worlds connected. I do not believe that all that we learned as business analyst in the waterfall era are completely useless. What has changed in the Agile world is how we think about analysis, how we present the requirements to our business and our development and testing teams. It is by no means a comprehensive and one size fits all document. But it does provide a start and a guide for those who sometimes cannot make the connection.
Using one fictitious ‘User Story’ in the Agile section of this document, I provide concrete examples of how and when to present just enough information, while giving your audience sufficient understanding of what they need to bring the requirements to life.
If we look at the previously proposed process end to end, it starts with the customer journey. The journey is mapped to the internal business processes, systems, and data sources. For both the customer facing and internal parts of the journey user stories are created to document the gaps between the as-is and to-be states - effectively form the backlog for the change. For each story, acceptance criteria are prepared in a way that enforces the expected behaviour in the system. Ideally, those should be the scenarios that are likely to appear on the real life journeys and not the hypothetical future scenarios. These scenarios when implemented and tested feed back to the journey and underlying layers changing them as the new functionality is introduced.
This question has been asked several times before, and various answers have been advanced to settle this matter. A short answer is ‘Yes’. But, unfortunately, this answer is not good enough to the ‘naysayers’, who think a business analyst has no place in Agile teams. To answer this question in a long way, we have to take the bull by its horns and talk about the elephant in the room. This article is an attempt to contribute to this ongoing debate. Whether you agree with me or not (as I tackle this elephant in the room), the truth is - this argument is apposite and has to be had.
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry we don’t do a great job of estimation. In this article I offer six safety tips to keep in mind as you prepare estimates for your project and for your individual work... These six safety tips might not help you create estimates that all of your customers, managers, and coworkers will dance to, but at least they will help you and your team hear the same music.
Let us look at it from a different angle now and derive the requirements out of the customer journeys. It is impossible to introduce a change... if the change is big and you try to implement it in one go. This is the reason we tend to break any solution into smaller components. Each solution component should be small and independent enough to be changed individually in a controlled manner. So that eventually we will compose a new experience out of them. Pretty much like using a set of Lego blocks.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: