This is basically the anatomy of a distributed team, working on requirements. Key point here is that this is the process working for us, in current configuration, and it’s effective.

Disclaimer: Every organization is different: from internal structure to how it communicates with the outer world. So no workflow is a silver bullet.

Disclaimer 2: SkuVault is an ever-improving team of ~50 people, distributed across 10 timezones, 2 different versions, and serving loyal clients worldwide 24/7. Learn more about Communication in distributed teams: Messenger & Rules, or Why we ditched Scrum, in favor of Kanban in JIRA

In order to let developer work as productive as possible, management should ensure the following bits related to her work are tackled:

• Requirements Fallback – whom to ask
• Issue Description & Decomposition
• No interruption

We moved closer to ‘no interruption’ bullet by creating on call teams, that are reacting to whatever urgent issues arise. (hållo to Kniberg’s Scrum from the Trenches 2nd edition – our own way of ‘firefighting teams’!).

However, there was no requirements preparation workflow a while back, so as the features grew more complex, more dependencies were discovered, we faced the inevitable given our product size: scope creeps, miscommunication, conclicting scenarios and inconsistency.

In order to bring all departments that were related to requirements eliciting and approval, we’ve created Product Management flow, which had to be highway to hell to better requirements.

Product Management Flow

We aimed to tackle the following areas by creating a formalized workflow:

• Easy to understand sequence of steps
• Each step has an accountable person, visible to all participants
• Workflow encourages Argumentation and Discussion -> no misinterpreted suggestions and details are hashed out collaboratively
• Each step ensures higher quality requirements, by providing criterias to be met on the output

Workflow consists of sequential steps: New Issue -> Discovery -> Sign Off -> Analysis

New Issue

Ticket is created by trigger from multiple sources (marketing, services, tech, customer support forums,..). During this state, the ticket is relatively empty, providing only the request and source of the request.

Transition: In order to move the issue to the next stage, Product Owner reviews whether we’ll ever do this feature. If no – he closes it. Yes, sometime – he moves the ticket to Backlog. Yes, near-future – he moves it to Preliminary Analysis.

Preliminary Analysis (Discovery)

Step Goal: Product owner should outline Feature goal (what we need to achieve, benefits for our company and customers); describe basic business process (general 1-2 sentenses on how it works among the warehouse, since we’re a warehousing solutions company); and add that to wiki-page for that feature.

Example: 

Brief feature description

Shipments are a way to track sale items that have been shipped to the customer of the Sale. A Shipment exists in SkuVault once a Tracking Number is assigned by the carrier.We want to provide an ability to connect and save tracking numbers, so that our users can have more visibility and editing right inside the app.

What do we want to achieve
Allow people that use shipping providers that don’t integrate with marketplaces as SkuVault
How it works on the warehouse

Goal: Allow clients to label products with tracking number, and see shipments in relation to Sale they are attached to

1. Picker gets to the QC table
2. QC performing person takes the product, QCs it and labels the product with shipping label and tracking number
3. The tracking number is added to the system and can be visible in relation to the sale
4. User tracks the product via tracking number

Stakeholder Sign Off

Since there’s quite a stream of tickets, we let Stakeholders approve bunch of tickets at a time. Someone might say ‘Hey, isn’t that Product Owner’s responsibility, to approve?’. Well, first of all our product is big and includes different areas and domains: services, marketing, tech, operations – all having their own pursuits respectively, even if we’re moving towards the same goal.

Step Goal: approve the idea, general process and timeline for the feature to be developed.

The next step would be to gather related parties and start..

Analysis

Analysis is biggest, most collaborative and complex part of the workflow. It involves:

[Business Analysts (creating User Stories)] => [collaborative efforts between BAs / UX / Developers (Wireframing)] <=> [BA / Developers (requirements adjustments, brainstorms, decomposition and clarification)].

Outcome: clear and atomized User Stories with Backend Subtasks with estimates, that give you ability to grasp and plan the feature for development. By you I mean us, Project Managers 🙂

Example: User Story – formalized and easy to grasp description, representing user activity and ability to interact with it.

Precondition: user is on Sale Info page

1. Before the user clicks a Shipment Tab in the Sale Info page, the hint at the top says “Click a Shipment for Detailed Information”
2. When the user clicks a Shipment line they see complete Shipment details at the top.
   1. list of fields for Shipments can be seen in Shipments – Plans / Technical Requirements
3. They can click a button for Shipped Items or Total Cost to see detail for the items.
4. If a Tracking URL exists for a shipment the user can click it to open the URL in a new tab.
   1. After new tab opens, user is navigated to shipping carrier website with tracking url info
   2. If there is not a tracking url user simple sees “Unknown” instead of the url.
5. If a Label (ie: PDF) is present, the user can view it in a new tab, or download it by clicking on ‘Download’ button

Post-condition: user is able to see related Shipments info

We got strict rules for creating user stories, technical tasks, support requests and bug reports. This ensures same standards across out task-tracking system (Jira, and properly used Kanban magic) for different issue types, and allows to interpret requirements with the single possible way (which is extremely helpful :).

Nutshell

Right, so in a nutshell, this dramatically increased our requirements quality, and gave us ability to start analysing scope creeps properly, visibility for similar projects and better prognosis. There are things to improve, such as redundancy removal from the requirements, optimizing time spent on the workflow, better communication when estimating client requests – we’re getting closed to that!

one more thing: “oh, author, your flow is redundant for smaller features!”. You’re right, just remove sign off phase and ease analysis to accomodate simple story description  for that feature / improvement ;).