10

TLDR They're a bunch of oxygen thieves who are holding you back. Either make them into useful people, get rid of them or have them guard the bees. Same point with more nuance (arguably): The BAs are essentially doing what would the job of the product owner and the customer should be doing. Potentially the preparation of stories is too much work for your ...


8

Here's my TL:DR answer: No! The engineer shouldn't be working on something if the business value isn't already defined. It's the voice of the customer (product manager, product owner, business analyst) that should be defining the business value. Said business value should be agreed to by the business before asking engineering to size the work for ...


8

To answer this effectively, it is important to split roles, job titles, and skills. Scrum has absolutely nothing to say about job titles, so we can actually resolve that fairly quickly by saying: as long as a particular "job" does not expressly conflict with Scrum, it is "allowed" in the Scrum framework.That isn't to say that particular ...


5

Leadership 101: Do not force the team to do something for the sake of doing something. On the surface, it seems to be a very nice idea, being poorly implemented. The straight answer for the question is no - it does NOT make sense to force engineers (coding-oriented people, who usually have collosal knowledge on programming but low communication skills) to ...


5

Your Posted "Stories" Are Goals, Not User Stories As an Ecommerce Executive, I want to make improvements to the Request a Callback form which will make it easier to segment the callback request by purpose. This is not in any way a useful (or even meaningful) user story. While user stories shouldn't be detailed specifications, user stories that are ...


5

If you reduce or remove a non value adding activity the overall outcome won't change, but the process time will be reduced. Often the non value adding activities take some time, but they can be caused by unnecessary transportation, doing things again etc. In Lean production they are called waste. A couple of examples: corrections: when you have to fix ...


5

A metric would be a standard of measurement in the context of PM. A performance indicator on the other hand is also just a type of performance measurement. Both terms could be and are used synonymously, e.g. here. The K in KPI would be the difference if any. One would consider the Key performance indicators the most important metrics that provide the best ...


5

A title is just a name. One of the first jobs I applied for just out of university was a position called "Superstar Programmer". Another was "Junior Programmer". Had I taken the first job, would I suddenly be a better programmer than had I taken the second? No. Of course not. You know what the job title was of the best Project Manager with whom I've ever ...


5

They're just different roles. A PM is responsible for guiding the project to successful completion. A Business Analyst is typically responsible for elaborating the solution from concept to detailed requirements. There can be conflict between the two roles, also. In some organizations, there is a combined PM/BA role. I tend to recommend against them, ...


5

Assuming that you are the Project Manager (otherwise, why would you post this to our site), you have no "right" to disclose this information to your team, since it was told to you in confidence. Your task as PjM is to ensure the project will be in a deliverable state by the "firing deadline" and that everything is well enough documented ...


5

TL;DR The canonically-correct solution is to put someone with business analysis skills onto the Scrum Team in a Developer role, and then cross-train the whole Scrum Team. Cross-pollination of skills enhances the capabilities of the Scrum Team and the Developers, and builds T-shaped people. Including someone skilled in business analysis on the Scrum Team also ...


4

Your data gathering is insufficient to arrive at any conclusions. If you only interviewed the original middle manager, and then other managers, you have missed many other data sources. You need to interview other employees; higher level managers; conduct focus groups and surveys; observe the work in progress; review company documents suchs as various ...


4

this is the job of the engineer working on the issue as they're the one most familiar with it. Technically, no. The engineer working on the issue is the one most familiar with the technical details of said issue. The one most familiar with the issue itself would be a Business Analyst (BA). Furthermore, engineers often have different priorities. I would not ...


4

I once read a case about a development organization - they were trying to improve the administration of justice in an underdeveloped country. They had a way to measure the administration of justice (IIRC, the % of decisions that were overturned on appeal or review). But they had no way to influence the actual decision. Root cause analysis indicated that ...


4

Your biggest problem is a toxic work environment. As you note, we yell at the technical person telling him almost literally that he is "not smart" enough to understand what we are trying to do. If someone were to do that to me, I'd immediately demand an apology. If I didn't get one, it'd clearly be time to update my resume... or perhaps even go to HR ...


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


4

Ignoring the substantive issue you're facing and focusing on the process of problem resolution, the general flow looks something like this: Clearly articulated problem statement: seems like you have that; Identification and analysis of potential root cause(s): seems like you have this, too; Analysis of Alternatives (various business model possibilities): ...


4

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to ...


4

There are two answers here - the Scrum answer and the my practical answer. In Scrum, there are three "accountabilities" (prior to the November 2020 revision, roles) on a Scrum Team - Scrum Master, Product Owner, and Developer. A team has one Scrum Master, one Product Owner, and everyone fits into one of these buckets. However, if there are multiple ...


4

I have seen many business analysts work well in Scrum teams. The three biggest challenges for them are typically: Reaching a clear understanding of roles and responsibilities with the Product Owner Adjusting to the just-in-time nature of Scrum - looking to add detail at the latest possible moment Becoming good at responding to change - taking feedback from ...


3

What are you doing to make sure you get the requirements that you want? I practiced as a BA for several years at a large company. I will tell you that this is not an uncommon problem that you are having. I can also tell you that the only way It gets fixed is when you and the BA get on the same page. Yes, the BA is supposed to document the requirements in ...


3

TL;DR; How much analysis is needed: enough analysis to enable the team to implement the user story. In most of the cases this means all information is available and there are no open questions. This should be done iteratively: the closer the implementation-sprint the more details are added. I personally think it is a good thing that you have the intendend ...


3

So if I understand right, your company thinks you should build an application for your customer. The customer hasn't requested it and you have no validation that the problem being solved even exists? How you proceed is really going to depend on where you fit in the overall organization. I'm going to assume you're a program/ project manager (given what this ...


3

Calling the top-management sounds pretty much like ignoring someone in the hierachy. If the PM is able to come up with functional requirements he has at least some business problems or market chances in mind - even if the PM is not able to formulate them, e.g. The customer would like to use a fancy tool in oder to "feel" cool. The company has to create a ...


3

Whether you're doing a big or a small project your approach should be something like this: Discover what the users want (go talk to them, for example) Build a smallest version of that (for example no user management, only with dummy data etc.) and ask for their opinion If they liked it, start working on improving the functionality (add whatever you need to ...


3

We differentiate between documentation for: Developers: This goes right in the source code and will be stored in Git. Whenever a function is added or updated, some "text in green" (our wording for developer documentation) has to be added. We write not only details & decisions about a function to it, we add additionally the reason why a decision was ...


3

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary. As an alternative to this you may prefer ...


3

Business analysts and Designers in a Scrum team Business analysts help provide detailed requirements to the dev team. So, in a Scrum team a business analyst can be a part of the Product Owner (PO) team and assist the PO. They can also step in place of the PO, when the PO is unavailable. However, designers actually do the work of creating a shippable ...


3

TL;DR Successful leaders measure project outcomes rather than individual productivity. Measuring individual productivity is generally an anti-pattern that obfuscates deeper structural problems. Do you have too many bugs? Turn your teams loose on reducing the amount of bugs released into production. Are bugs taking too long to fix? Get your developers and ...


3

Scrum just says that the team needs to have all the skills needed to build the product and all the product increments leading up to the final result. Although no other role than "developer" is identified in Scrum, teams often contain specialized skills, like front-end developer, back-end developers, testers, designers, etc. So if the product you ...


Only top voted, non community-wiki answers of a minimum length are eligible