Hey BA! Are you feeling befuddled, bemused, battered, or brain-dead? Never fear, Betty the BA is here. Ask her anything.
My team is switching to Agile, and I’m not sure what my role is going to be! Am I going to lose my job? Is there even a BA in an Agile team?
– Nervous in NY
Every software project needs requirements analysis, regardless of the software development methodology! At the program, project, and team level, there are people eliciting requirements, doing analysis, documenting processes, and prioritizing the work. They have different titles in an Agile organization, but they are still super important. All of your hard-won BA skills are still really needed, so hang in there!
I’ve recently taken a new job, and I’m still getting used to this place. It seems like everyone is in meetings all the time, which makes it really hard for me to get time with stakeholders. But, if I send an email asking for information, I either don’t get an answer or I get a really sketchy answer that doesn’t actually help. How am I going to elicit requirements if everyone is too busy for me?
– Desperate in Dallas
I feel your pain! This is a common complaint. Organizations CAN make changes to reduce the meeting overhead, but in the meantime, you’ll need to catch people in the hallway, at their desk or via instant messaging to introduce yourself and ask for a commitment to meet. People won’t give you much time, so get your elevator pitch ready. An example: “Hi, I’m ____ and I’m working on ____ and I need 30 minutes of your time for ___. When can you meet with me?” Make sure that first meeting has a manageable agenda and an achievable goal so that your stakeholder can see that you won’t waste their time, and they’ll be more likely to agree to follow-up meetings.
I’m working on a program team and I’m trying to coordinate requirement backlogs across multiple teams. One team uses TFS and has 2-week sprints, and another team uses Jira and has 4-week sprints. How am I supposed to keep track of what’s going on?
– Frantic in Frisco
Dear Frantic in Frisco,
Here are a couple of tricks to help you out. First, if you have interlocks between the teams to manage, track to “finish by” milestones instead of sprints to accommodate the different development calendars. This will reduce confusion. Second, ensure that you hold regular scrum meetings with representatives from all the interlock teams, since they probably don’t have visibility to each other’s backlogs, to ensure that issues are raised and information is shared. Third, track and publish status at a feature instead of user story level, to reduce the “management overhead” for teams. You don’t want them to get so bogged down with administrative work they don’t have time to develop and test!
There’s a stakeholder on my project who always seems to amp up every project issue. He’s got everybody on edge all the time. I’m told that HR frowns on bringing hemp brownies to meetings. How do I get him to chill
– On Edge in El Paso
Dear On Edge,
The approach you take depends on HOW he’s amping things up. Sometimes people are so eager to avoid taking the rap for a problem that they spend a lot of time looking for someone to blame. If that’s the case, then you can calmly state “We need to work the problem. Where do we go from here? The past is in the past.” On the other hand, he may simply not be applying perspective and treating all problems, large and small, as project-cratering catastrophes. In that case, take a metrics-based approach. “What is the potential cost of this problem? How much will it cost to fix this problem? What percentage of time do we expect this problem to occur?” Sometimes people spend a lot of time worrying about an edge case situation that has a very low probability of happening in real life, and you don’t want to waste a lot of resources focusing on those.