7

This is a great question. Several years back I analysed the bugs reported in a team and found that over half of them came about as a result of misunderstanding of requirements. Some things that can help to reduce this problem include: Have the team (QA, devs, PM, etc.) jointly add details to a requirement, so that they share a common understanding Using an ...


5

If there are two stakeholders who have different understandings of the requirement, then there may be more. What about how you interpret the requirement, from the perspective of a tester? Or how about the customer? Or even the end-users of the product? If the requirement is ambiguous to the point where two people who (in theory, anyway) are working closely ...


4

TL;DR You have mixed some concepts. As Stanislav has written; there are two approaches. Predictive and Adaptive Within Adaptive you may find both incremental and iterative which are distinct from each other. However, it is highly likely that Incremental is also found within Predictive models. How Does That Work? Increments are pre-defined packages of ...


3

For me, it wouldn't make any difference if you did all the testing, B did all the testing or if you shared the effort. Nor does it make a (big) difference if what you notice in production is a new problem, an incomplete fix or a regression. In all cases, you should follow the procedure for reporting and assessing a problem found in the production environment....


2

Welcome to PMSE! It's very normal for people to have different understandings of a requirement but what is interesting is that you haven't mentioned the person whose opinion matters most of all: the customer. The way to deal with your situation is to collaborate closely and frequently with your customer (sponsor / product owner / end-users), deliver results ...


1

I have written about the scientific evidence on teamwork for 20 years. I like your thinking. There are pretty solid answers in the research literature: Yes. Anything you can do to give the team more control over its work is likely to improve measurable team performance and worker satisfaction. Shorter objectives are more motivating, but longer goals can be ...


1

You need to define further what you mean by, "...is not being tested properly". Was the testing not proper because the tester improperly performed the test or was it improper because the test was inadequate? Without an answer to the root cause, you have no possible action. So to answer your question, your best approach is to uncover the root cause. ...


1

I am going to answer this question more generically because deconflicting stakeholder issues should not require different methods based on who the stakeholders are or what the tasks are. Different opinions, interpretations, and perceptions are a given on any complex project so the team should have a process by which these issues are escalated, examined, ...


1

You don't need the design documents on Confluence to live in the Jira report. The electronic traceability through the Jira and Confluence UI should be sufficient if you even need that. Although the traceability reports may be helpful as an export, the most important traceability is between the Jira ticket (often a Story or Bug, or something similar), the ...


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