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?

In Part 1 of this series John Seddon argued that Agile, as practiced, is bereft of knowledge, hence its ubiquitous failure. Here he argues that ‘get knowledge’ is the starting-place for effective change.

Part 2: Knowledge: the prerequisite for profound change

It may seem heretical to suggest that we make change without knowledge, but, as Deming pointed out, experience is not equivalent to knowledge; you can spend 20 years in an organisation without knowing how to change it for the better. Leaders, clients and stakeholders describe requirements or problems to solve on the basis of their current world view, governed by information from their current control systems, but what if their world view is flawed? What if there are bigger and different problems to solve?

Five S can be applied in any work environment and prepares a work area for a follow-on Lean process improvement effort. In this case, 5S prepares my garage for Lean process improvement in doing home activities like automobile maintenance, appliance repair, and hobbies like gardening and woodworking. But, remember the preparation benefit is only realized if 5S is sustained. As I said I am the worst (ugly) in keeping the “new world order” in my garage.

The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, the Future-How, which looks at the solution to the business problem. It does this by assessing alternatives, and then choosing the best solution to that real business problem.

For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, requirements are documented to bridge that gap. You are reading this because you are a business analyst responsible for documenting detailed requirements and, in the case of this article, business needs involving one or more user interfaces (UIs) or reports.

The objective of this article is to answer the question, “How much detail is necessary?” Spoiler alert – quite a bit. This is to avoid, as much as possible, a BA having to go back to a SME when designers or developers have business-level questions about a UI or report. Or worse – designers or developers not asking questions. Instead, making assumptions about what the business needs and proceeding to deliver the solution based on those assumptions.

Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea – business logic should not be buried in procedural programming languages. Call it rule independence.  Why is rule independence important to you? Because rules entangled in procedural code won’t ever be agile. Rules change all the time – and in a digital world the pace of change is always accelerating. How you can stay on top of it is the central question in business agility.

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.

Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations. The first article in this series described what mental models are and talked about the first mental model covered, second order thinking. In this second installment we discuss another mental model that that can help business analysts become better problem solvers: integrative thinking.

Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.  When we talk about a requirements document we are often referring to a Business Requirements Document - or a BRD.  But as well as a BRD, there are 9 other types of requirements documents that a business may want to use while pushing a project through its stages of completion. The type of format to be used depends on the result of the project itself, whether it’s a product, service or system, and the particular requirements it has.

John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information technology the last thing to be concerned with, not the first.

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.

The ethics behind accessibility is possibly not something you have considered before. I think many would categorise an accessibility tool as something that; ‘makes life easier’, for a disabled user. However, what we should be taking into account when designing new digital platforms is how to make sure that every single user has the same experience. This is actually a very key point as we are not even specifically talking about disabilities here.

Have you considered mobile users vs web? IOS vs Windows? Online vs Offline? These are all possible different users of your system and all deserve the same experience. It may well be that a lot of these points are non-functional requirements that come later in the development, but if you make sure you are considering them at the start, you can save yourself a lot of time and effort in the future.

The previous article in this series discussed ensuring that high-level requirements (HLRs), within the context of an IT-based project, were properly high level. The remainder of articles in the series will look at detail requirements and the need for them to be sufficiently detailed. The objective of this article is to demonstrate how a data dictionary (DD) can be used as a tool for capturing the appropriate level of detail representing data-specific business needs.

The purpose of the Trips-R-You Flight Booking Case Study is to provide an integrated, end-to-end set of requirement examples. In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. This case study, and associated artefacts, use the more traditional business terms Goals, High-level Requirements (HLRs), and Detail Requirements. Only functional requirements are addressed, and only within the context of a project chartered to deliver an IT-based solution.