Product Management: Development Process

Question 1

Waterfall process

Answer 1

Gather Requirements : The requirements must be fully captured and defined through rigorous documentation in the form of an elaborate requirements document.

Design the solution : The requirements are utilized to design the product that details the functional or system requirements and aids in defining engineering architecture. The requirements and solution may be functionality focused instead of being customer-centric.

Develop the solution : The scope of work is broken into smaller manageable units and developed independently. Each unit of work is tested to confirm whether the intended functionality has been developed and this is called as Unit Testing

Test the solution : The units developed and verified in the previous phase are combined or integrated. This integrated system is tested thoroughly for any issues or failures.

Deploy the solution : Once the product has been exhaustively and comprehensively tested, it is deployed to the production environment for customers to start using it.

Maintenance and support : When issues arise, they are fixed. Enhancements to the product go through the same process to deliver the changes Each phase requires a sign-off from an approver ( for e.g. in the case of Gather Requirements and Design the Solution - it could be the enterprise customer for a B2B2C product) to ensure there is no overlap between phases ( e.g. gather requirements and design the solution).

Question 2

Kanban board for development

Answer 2

1 Product Backlog

2. Ready for development
3. In progress
4. Code Review
5. Testing
6. Verified
7. Done

Question 3

INVEST Criteria for User Stories

Answer 3

INDEPENDENT
Each story is self-contained and not dependent on another story

NEGOTIABLE
Focuses on capturing a user’s needs without restricting how the user’s needs are resolved

VALUABLE
Focuses on providing a clear value to the customer or end-user

Estimable
Can be costed during sprint planning to effectively fit into a sprint

SMALL
Can be developed and tested by the Scrum team

TESTABLE
Can be tested using the acceptance criteria and definition of done

Question 4

4 main ways of writing acceptance criteria

Answer 4

Use-Case Scenario: Given, When, Then
Negative Scenarios/Boundary constraints
Rules-based
Must have edge cases

Question 5

Use-Case Scenarios

Answer 5

Describes what happens when a user interacts with a feature

Can be written using the Given, When, Then

(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should obtain
An example:

Given my bank account is in credit, and I made no withdrawals recently,
When I attempt to withdraw an amount less than my card’s limit,
Then the withdrawal should complete without errors or warnings

Question 6

Negative Scenarios and Boundary Constraints

Answer 6

Describes what happens when the user provides invalid input or behaves unexpectedly

Question 7

Rules-based Acceptance criteria

Answer 7

Describes requirements a feature must meet

e.g.) Placeholder copy disappears once user starts typing in results

Question 8

Must-have edge cases Acceptance criteria

Answer 8

Low probability scenarios that must be supported to avoid poor user experience and disappointing the customer