Agile Methods

17962 Views
15 Likes
0 Comments

One of the biggest challenges now facing business analysts is this: how do we successfully engage with stakeholders, elicit requirements, and have productive workshops and meetings, without actually meeting in person? The tried-and-tested methods of getting together in a collaborative space, using sticky notes and whiteboards, and bribing attendees with baked goods, are no longer quite so straightforward in a world where some or all of the stakeholders are on the far end of an internet connection.

There are several factors to consider when moving out of the purely physical realm as a business analyst.

21555 Views
18 Likes
0 Comments

How do we know when a user story is “done“? Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Business representatives may say yes, but they do not know all the peculiarities of software development. So, such criteria as quality are not fully visible to them.

Or let’s have a look at another situation: a new feature that changed the business process was developed and tested according to the best software practices, but users struggle to use this feature because they are not sure about the changes this feature brings. Maybe a proper user manual or user training is needed in this case?

In this article, a simple, but very powerful technique which is called Definition of Done (DoD) is explained.

23694 Views
25 Likes
0 Comments

My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in the Scrum framework).

16006 Views
3 Likes
0 Comments

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.

16992 Views
3 Likes
0 Comments

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.

19899 Views
22 Likes
2 Comments

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).

10573 Views
78 Likes
0 Comments

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. 

13899 Views
3 Likes
0 Comments

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.

12387 Views
3 Likes
0 Comments

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. 

14742 Views
14 Likes
2 Comments

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.

21225 Views
61 Likes
2 Comments

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.

10995 Views
24 Likes
0 Comments

 

Step one is get knowledge, step two: redesign for effectiveness then, lastly, step three, pull in IT. It is to start from a base of knowing what IT can do to support a more effective design, the costs of development drop to tens of thousands and everything developed gets used – an amazing feat in IT development. And the benefits delivered by the IT system are significant: Real-time visibility of the work, accurate information about demand and activity times, costs and materials employed.
14265 Views
25 Likes
0 Comments
Have you heard of agile business analyst? Does this even make sense? Agile is to move quickly. How can a business analyst move quickly when (s)he is loaded with effort of understanding the scope, collecting, analyzing, and defining requirements, convincing and negotiating with stakeholders, make a technical team understand the requirements and ensure delivery as committed?
15379 Views
25 Likes
0 Comments

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.

27295 Views
64 Likes
5 Comments

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.

Page 2 of 10First   Previous   1  [2]  3  4  5  6  7  8  9  10  Next   Last   

 



 




Copyright 2006-2024 by Modern Analyst Media LLC