Writing User Stories
The Product Manager is responsible for writing user stories of all types.
However, there are times where the developer’s input might be necessary. For example, if the developers identify a chore that is necessary to implement a feature, developers should often be responsible for writing that chore.
As an engineering-focused company, our Product Managers write very small and detailed user stories. Each user story should be bite-sized. It must cover the smallest possible area, and there must be one user story for each implementation level (e.g., backend and frontend).
For web projects, there are at least two implementation levels and sometimes more.
- Backend: where the business logic gets implemented.
- UI: where the UI and UX get implemented.
- API: for projects where the backend and the API are separate layers.
- UI: where the application UI and UX get implemented.
- Backend: where the connection to the APIs and data fetching gets implemented.
- Integration: where the UI connects with the backend.
For example, we will be using Nimble’s Survey app, which we use for internal certifications. Let’s also focus on the login part exclusively to keep it short.
- Web project: https://www.pivotaltracker.com/n/projects/2468046
- Mobile (iOS) project: https://www.pivotaltracker.com/n/projects/2468212
Pivotal Tracker workspace showing the demo Survey apps backlog for web and iOS.
Bug-free software does not exist. It is unrealistic to expect no bugs in an application. However, it is essential to properly document bugs when found so that the Engineering team can identify them and fix them quickly.
Four key pieces of information are required when reporting bugs:
- Environment, to narrow down the conditions under which developers can reproduce the bug.
- Steps to reproduce, to let the developers know how to see the bug occurring.
- Expected outcome/behavior, to clarify what is considered the functioning feature.
- Actual outcome/behavior, to detail when is happening but should not be happening.
Product Managers and stakeholders are strongly encouraged to attach materials to help with the investigation work: screenshots, screencasts, references to similar or related issues, etc.
# Environment - Platform: web/Android/iOS - Device: e.g., iPhone 10 - OS: e.g., iOS 13 - Version: e.g., 0.12.0 (519) - Environment: staging/production # Prerequisites Specify if there are specific conditions that must be met to recreate the issue. For example: Use an account with no chat history / The app must be freshly launched / Launch the app from the already signed-in state with an account registered with mobile no. # Steps to Reproduce 1. X 2. X 3. X # Expected Describe the expected outcome. Add screenshots if possible. # Actual Describe the actual behavior. Add screenshots and screencasts.