fbpx

Let’s face it, in order to build working solutions, the analysis must happen!   Notice I said “working” and let me clarify what I mean by that!  I mean working as needed for the users and intended value the business leaders wanted.  I do not mean simply a clean compile and testing complete.

I would argue that if solutions are implemented and are not working (working as in my definition above), then the analysis either did not happen at all or is flawed.

For many decades we have seen this play out.  A solution is implemented and it works, or all too common, a solution is implemented and it doesn’t work and is fraught with enhancement requests and defects, or even worse, simply not used.

Agile has been around now for 20 years (agile as a term in software), whereas the practices have been around much longer.  After 20 years, there seems to be continued conversation about the BA role on agile teams.  For the purpose of this article, I want to set that conversation aside and instead focus on how analysis happens on agile teams, BA or not.

If Agile teams don’t have BAs they still do analysis, they have to!  The question is how good are they at it?

Analysis is a skill with many techniques to learn and master to do really good analysis and make the solution usable and valuable to the users and organization.  Really good analysis is the kind that minimizes rework, gaps, and keeps teams working efficiently.  Great analysis uses advanced facilitation techniques, modeling techniques, questioning techniques, customer and data analysis techniques decomposition & abstraction techniques to help a team create a shared understanding in problem-solving and decision-making.

Agile analysis is not a phase, and does not have the team “waiting for requirements”, it is done in layers, just in time, and helps the team work faster by having the right work prioritized and lined up to get the user and business value delivered in small chunks that allow for learning, feedback, and innovation.

For some teams, the “development team” does the analysis.  I find that in many large organizations this is not the case, as the teams are not skilled as deeply in analysis skills and are not used to doing this work.  In this case, the team needs a very dedicated, hand on Product Owner who can do the analysis (big picture and all the details with the team) and/or a BA on the team.

For smaller organizations where the development team is accustom to doing analysis (thinking about the user flow end-to-end, analyzing the data flow end-to-end, the rules, logic, and the user need) as part of their work, well then they are doing the analysis.  This type of team may need more “developers” to get the same amount of work done as they are taking on more of the work to prep the backlog, research, spend time with users, and analyze the various flows of the user experience, data, rules, process, and logic.  They need to spend more time analyzing the various user scenarios and together have a more holistic view of the user throughout the user’s journey interacting with the entire tech stack.

A team without good analysis skills will struggle to meet its product and sprint goals.  They will experience carry over in stories that just don’t seem to ever get done, and they will lose focus between keeping the customer experience, data intelligence, business process, data flow, cyber security needs, and technical excellence all in a juggling act that is at best hard to follow and keep all considerations on track.  A team without good analysis will also struggle to keep technical debt at bay and struggle to estimate mid and longer-term.

Successful agile teams have deep analysis skills, the title or role is unimportant, more important is that the team has the skills.  In large organizations, this may be a Business Analyst that brings these skills to the team.  Or a Product Owner, or in many cases a team (BA and PO together). Great analysis on an agile team helps connect the customer needs, strategic vision, data, technical, and other aspects in a coordinated set of assets the teams use to help keep it all in view and prioritize and discuss these often conflicting needs in a healthy manner aligned to the product vision.

How do you know analysis on your team performing well?

  • The backlog is transparent and includes short, mid, and long term work
  • The backlog is detailed and refined for about 2 or 3 sprints/iterations out
  • The Team uses real feedback from users to inform and plan
  • The Team works with the Product Owner to manage the backlog priorities
  • The Team works on the detailed user scenarios as they work, the design details, and the testing scenarios as the team works keeping the user point of view in mind while they work
  • The Team has conversations on customer value during the sprint as design decisions are made
  • The Team defines increments of value with the PO and Dev team as they refine the backlog
  • The Team uses visual models and deep facilitation skills to help the PO and team identify user stories and acceptance criteria
  • The Team assesses the solution for how well it is working for the users and the intended value
  • The Team gets user feedback proactively and works with the PO to prioritize and decide what to incorporate

If you have a BA on the team, you can simply substitute “BA” for “Team” in these to understand what a great agile BA does!

How does analysis happen on your team?