If you think Agile methodology means the death of the business analyst (and documentation), think again. I was recently preparing for an interview with an agile development shop and here’s some of the best resources I found:
- Agile Business Analysis Interview with Scott Ambler (Modern Analyst): Good interview with lots of supporting data. Key quote: “I was surprised that Agilists were just as likely if not more likely to write documentation.”
- Agile Requirements Modeling: The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to on a just-in-time basis. This article also puts developers in the role of “analyst”, but, in my not-so-humble opinion, it doesn’t have to be this way.
- Scaling Software Agility, Blog by Dean Leffingwell, author of Managing Software Requirements (my original go-to book for requirements). He writes too many great posts to list just one here. Dean’s blog deals with virtually any topic related to agile development methodologies.
- Agile Business Analysts: While some of the above posts talk about requirements activities, but not a business analyst role, Akshay Dhavle speaks about his experience as a BA in an agile environment.
- Advantages of User Stories for Requirements: Article explaining how requirements are done in agile development, including a detailed explanation differentiating use cases and user stories.
This interview turned into a contract for me. I hope to transition from enlightened observer to agile practitioner soon. Look for more along the line of best practices in the coming months.
How do you see the BA role within an agile environment?
- Writes user stories (16%, 22 Votes)
- Writes user requirements (15%, 21 Votes)
- Involved in demo / retrospective (15%, 21 Votes)
- Involved in planning the sprint (13%, 19 Votes)
- Develops product backlog (13%, 18 Votes)
- Creates mock-ups / wireframes (10%, 14 Votes)
- Prioritizes product backlog items (9%, 12 Votes)
- Conducts testing (9%, 12 Votes)
- Designs software (1%, 2 Votes)
Total Voters: 141
Loading ...
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
{ 4 comments… read them below or add one }
Thanks for the links to some great resources, Laura.
If your interview with an agile development shop turned into a contract – I guess that means they still believe in the role of a BA, right? (Congrats, by the way.)
While the role of the BA varies widely in industry, there is definitely room for a BA in agile organizations. Somebody needs to get the stakeholders in alignment about what problem is being solved – regardless of the development approach.
I’m curious, do you foresee yourself working as a representative of the development team to the stakeholders, or the other way around?
Hi Matt,
Thanks for your question. I agree (and am proof, I suppose) that the BA role has value in agile organizations.
I think you’re trying to catch me on a trick question.
I see the BA role, regardless of development approach, as bridging communications between both sides…representing the business community to the development team and bringing technical concerns to the business. I don’t see that changing for this particular contract.
Greetings!
BA should mean – in my not so humble opinion – Business Architect as well as Business Analyst. A BA is a person who is part of a well formed Product Management team and, thus, is (or should be) both forward thinking and thinking about how business works today.
Whether or not agile is your chosen methodology, the BA role is fundamental … especially for larger systems and platform development. And it is here where systematic thinking in system development can begin …
How do you see a BA in today’s enterprise software development context becoming more of a Business Architect … working with the executive Product Management (or analog IT) role to ensure that platforms today can be systematically evolved?
Our Business Analysts were highly involved in designing our software, so the poll above surprised me. The BA’s were often the only ones that had worked in the type of office we were writing software for, so they were the customer voice (internal to our organization). They ran the design meetings which we called feature blitzes and emailed the starting points for user requirements prior to these meetings.
I was more surprised that the BA’s were not writing the User’s Guides, as that was one advanatage of “agile”, having a manual to release with the software, that wasn’t written at the last minute and had been fully tested and proof-read by QA.
We did backlog, etc. differently too, so though I fear that a longer post may not be read, one that is too short won’t demonstrate the interactions of the roles. Here’s the long post:
I participated in a group that implemented many “lean” methodologies (an agile-scrum-six sigma hybrid peppered with our own ideas and processes for our “Try This” ideas). This department was able to double programmer productivity almost immediately—but there was some temporary stress increase as the change from waterfall to agile was made—they were able to produce a User’s Guide for each feature while the programming and QA was happening, and they were able to release features most needed by customers in a truly agile and quick manner. They accomplished this by the following practices and some others:
An analyst prepares some ideas for a project’s features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role’s work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone’s time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role’s work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User’s Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn’t going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.
We used a Quality Function Deployment (QFD) chart in Excel to prioritize our Backlog.
Each person (Programmer, Analyst, Code Reviewer, & QA) puts in their estimates for the stories they are assigned.
Each manager puts in the person’s hours capacity for the iteration.
Stories are swapped around until everyone is at full capacity.
We had a commit rule that if you committed, you did overtime and got comp time another iteration/week. Everything was done on time, unless the roadblock was from another department, somebody had surgery, or some other insurmountable “event”.