Feature Project Delivery 

Framework 
V2.8 28/Mar/2018 
 Feature Project Delivery Framework 

Version  Changes  Update Date  Done by 

v 2.0  Initial document for internal review.  Oct, 13. 2017  Pau Minoves 

v 2.1  Internal Feature SEM feedback applied.  Nov 2, 2017  Pau Minoves 

v 2.2  Added project delivery framework  Nov 2, 2017  Pau Minoves 

appendix draft for internal review. 

v 2.3  Story workflow and environment  Nov 14, 2017  Pau Minoves 
definitions changed to match SE7 and 
maintenance workflow. 

v 2.4  SE7 adaptations: verification  Nov 28, 2017  Pau Minoves 

descriptions and SLAs + Failed Fix. 

v 2.5  Refactored blocker playbooks. Added  Dec 19, 2017  Pau Minoves 
playbooks for Bug fixing and Non 
capability work. 

V 2.6  Added SLAs definitions  January 24, 2018  Alexey Syrtsev 

V 2.7  Feature Delivery Framework extracted  February 15, 2018  Pau Minoves 
to its own document. 

V 2.8  Moved SLA description from Feature  March 28, 2018  Pau Minoves 
Playbook. 

V 2.9  Added Customer Review auto-approval  May 2, 2018  Alexey Syrtsev 

process description 

V 2.10  Updated Feature Story workflow,  May 18, 2018  Alexey Syrtsev 
removed Fix On-Time SLA, introduced 
Feature Defect initial description 

V 2.11  Feature Defect workflow description  May 27, 2018  Alexey Syrtsev 
Feature Story SLA diagram update 

1 
 Feature Project Delivery Framework 

Related documents 4 
Projects portfolio 4 
Playbooks 4 

Project resources 5 

Team work 5 
40h / week 5 
Days-off 5 
Time zone overlap 5 

Technology standards 5 

Program managers 6 

Ship Every 7 6 

Project meetings 7 
Sprints 7 
Planning meeting 7 
Weekly Demo 7 
Project Daily Standup (DSU) 8 

Task management 8 
Issue types 8 
Milestone workflow 9 
Capability workflow 10 
Task workflow 11 
Feature Defect workflow 12 

Environments 13 
Local environment 13 
Development environments 13 
QA environment 14 
Staging environment 14 
Production environment 14 

Code workflow 14 

Feature branches 14 
Feature pull request 15 
Development branch 15 
Master branch 15 
Release branches and staging cut pull request 15 
Production release 16 

Continuous Integration 16 

2 
 Feature Project Delivery Framework 

Project creation and handover (for Feature SEMs) 18 

Appendix 1 - SLAs 19 

Overview 19 
Monitoring 19 
Escalation 20 
SLA - ‘Story Validation On-Time’ 20 
SLA - ‘Story Review On-Time’ 20 
SLA - ‘Story Verification On-Time’ 21 
Feature Defect SLAs 21 
SLA - ‘Feature Defect Engineering On-Time’ 22 

3 
 Feature Project Delivery Framework 

Related documents 

Projects portfolio 
Eng.Feature Project Portfolio​ (2018Q1, 2018Q2 and beyond merged on Delivery Dashboard 
below): A dashboard that contains: 

● List of active projects

○ The Eng.Feature scorecard value for every project
○ A link to the Eng.Feature Project Playbook for every project.
● The Eng.Feature scorecard template.
● The Eng.Feature Input Quality Bar.

Playbooks
Eng.Feature Playbook​: Feature SEMs playbook. 

Eng.CoreSEM Playbook​: Feature SEMs are also Core SEMs and abide the same playbook. 

Eng.Product Playbook​: Product SEMs are the ordering parties for Eng.Feature and the main 
consumers of Eng.Feature output. Eng.Product also contains relevant SE7 practices. 

Ship Every 7 description​: SE7 is an extended delivery framework that governs the relationship 
between Product SEM and various core team rooms, including Eng.Feature. 

Dictionary Dictionary

4 
 Feature Project Delivery Framework 

Project resources 
Projects must have a drive folder that groups all relevant documents, like specifications, 
meeting recordings, etc.  

Projects must also have their own project playbook that document project specific 
information, like links to resources, procedures, ramp-up material. 

The layout for the folder is free. Both project playbook and drive folder, must be linked from 
Feature Delivery Dashboard ScoreCard 

Team work 
It is important that both ICs and Feature SEM show their best behaviour and online netiquette 
in order to ensure that projects can run productively on such a remote setting. Most 
importantly, make an extra effort to be a good communicator to the rest of team members. 

40h / week 
Every IC is expected to work 40 hours a week. No more, no less. In the rare cases you need 
to do overtime, ​contact your Feature SEM​. 

Days-off 
A day where you work 4 hours or less is considered a day off. 

To request one or more days off create an event on the vacations calendar that your Feature 
SEM will provide you and request approval via slack. At least 15 days notification period is 
expected for more than a single day off.  

In case of emergency unplanned day off, email your Feature SEM with current task status, 
emergency reason and ETA to be back in office. 

Time zone overlap 

Know your teammates timezone and target at least 3-4 hours of daily overlap. Let them know 
of your working hours. 

Technology standards 
The Product SEM and its team provide the technology guidelines that must be in place for the 
development activities. They do so by providing the following artifacts: 

● Technical guidelines for development

5 
 Feature Project Delivery Framework 

○ A document describing the technology choices, library constraints and in

general any rule that developers must observe regarding code writing.
○ Example, DevFactory Technical Guidelines.
● Pull Request QE checklist
○ The checklist that QE team will use for reviewing PR.
○ Developers can use this to reduce largely the PR rejection rate.
● A project maturity checklist.
○ For multi-product or  multi-project developments, allows to track that all
projects are aligned.
● Features that are major enhancements and require architecture/design changes
would need to be reviewed and approved by identified members of the Product team.

On top of that, in order to guarantee our own output quality bar, the Eng.Feature teamroom 
defines a simple set rules that must be observed even if not explicitly specified by the Product 
SEM team. They are reflected on the ​Feature Delivery Dashboard ScoreCard​ scorecard, ​QE 
section​. 

Program managers 
Program managers are added to core teams on some settings (ie. DevFactory). When added, 
the program manager takes some of the Feature SEM responsibilities, concretely: 

● Prepare milestone demos and perform them to product team.

● Assign tasks to ICs according to project priorities.
● Manage Jira sprints and tasks, leading the planning meeting and dailies.
● Create Epic (milestones) and Story (capabilities) tickets on Jira.

From the product team, the program manager takes the following responsibilities: 

● Validate capabilities on Ready For Validation state.

For the extend of this document Feature SEM references are used globally for both SEM and 
Program Manager duties. 

Ship Every 7 
SE7 is an extended delivery framework that governs the relationship between Product SEM 
and various core team rooms, including Eng.Feature. 

The SE7 framework is described ​here​ and implies some variations on the Eng.Feature Project 
Delivery Framework described in this document. These variations are pointed through the 
project and can be summarized as: 

● Potentially shippable product version is delivered on 7-days pace

6 
 Feature Project Delivery Framework 

○ A release (staging cut) is created at a fixed day every week (by default
thursday), regardless of milestone completion.
● Potentially shippable product version is of a good quality
○ Offending changes are rolled back if defects are detected, and entire release if
number of defects exceeds a certain threshold.
● All involved teams are kept aligned
○ Orchestrated by Product SEM.
● Feedback on code quality is received on the same day the code is done
○ Reported defects are fixed with maximum priority.

Project meetings- 

Sprints 
Teams are encouraged to do one week sprints. Feature SEMs can decide to change the 
sprint length to accommodate project peculiarities. 

Sprints are used to make ICs aware of their weekly scope and responsible on how they will 
meet their productivity metric. 

Planning meeting 
All team members must have read any specification, new or existing, that is relevant to the 
tasks in scope of the sprint. Use the comment system on the documents to clarify doubts 
early. 

Feature SEM must create a sprint on the team Jira board and tag scheduled issues with it. ICs 
must make sure they finish the planning meeting with enough work assigned to meet their 
personal productivity goal. All the tasks in the sprint backlog must be assigned by the end of 
the meeting. 

It is encouraged to spend little time on estimations. We are after rough sizing, not detailed 
and accurate estimations. Consensus estimation techniques like planning poker are out of 
scope. 

Weekly Demo 
Demonstrate Capabilities that were completed in the previous period, and are scheduled for 
next SE7 release, to Product Engineering teams, Product Managers and business users.   

Alternatively, the Feature SEM and product team can decide to schedule this demo monthly, 
quarterly or after a public release. It is also acceptable to avoid a demo validation meeting in 
favor of demo videos attached to capabilities on Jira. 

7 
 Feature Project Delivery Framework 

It is however, mandatory that capabilities are validated on a weekly basis to allow for weekly 
releases as required by SE7. 

Project Daily Standup (DSU) 

An all ICs and Feature SEM meeting happening every day at the same time, for a project or 
group of projects. The goal for the DSU is to share overall project status, as well as, determine 
if there are any blockers that prevent an IC from progressing towards a goal and unblock the 
IC if there are any such blockers. 

Task management 
Jira​ is the tool used for planning and tracking. A single centralized Jira instance is used by all 
the products to manage their processes. This instance can be found at 
https://jira.devfactory.com​. 

Explanation of the entire Jira workflows involved is out of the scope for this document. Please 
find extended workflow description ​here​. In this sections we will just comment on required 
actions from Eng.Feature. 

Issue types 
There are five types used in feature projects: 

Epic  Use to represent on Jira an approved L1 specification scheduled for 

delivery, also called milestone. It serves as parent type for the Stories 
and has its own approval process. 

Feature Story  Used to represent L1 capabilities on Jira. Each Story in Jira must relate 
to one and only one capability on the L1 specification. 

Only Stories are counted towards the productivity metric, and they 
must always be approved by the product team.  

Development  Sub-task of Story, can be used to decompose a story into developer 

Task  actionable tasks. 

Feature Defect  A defect found on a delivered Story. 

Task  A task is a general, non-business oriented activity that needs to be 

performed by the development team. Examples of tasks are 
deployments, configuration management and continuous integration 
maintenance activities. 

Make sure your Jira projects is using the correct workflows: 

Aurea-Eng.Feature-Epic-2.0 
Aurea-Eng.Feature-Task-1.0 

8 
 Feature Project Delivery Framework 

Aurea-Eng.Feature-Story-2.2 
Aurea-Eng.Feature-Feature Defect-1.0 

Milestone workflow 
An L1 milestone is represented in Jira with an Epic issue type. 

New  A new Epic is created on Jira by the Feature SEM when an 
approved Spec is handed over to development team.  

On this stage L2 and L1 documents are linked and capabilities 

(Stories) are created below, each with its Definition of Done.  

Once the Epic is created, the stakeholder should review if it 

was indeed created according to the submitted spec. If 
everything is ok, he moves it to Backlog. 

If the Epic ticket is linked to a SPEC ticket using a “relates to” 

link type, the SPEC ticket must be in Engineering Backlog 
status. 

Backlog  If the user who triggered the transition is on the PdM Jira 
group, child Stories will be moved from To Define to Backlog. If 
not, the epic will be moved to Backlog, but its stories won’t. 

On transition to In Development, the linked SPEC ticket is 

automatically moved from Engineering Backlog into 
Engineering Active. 

If the SPEC ticket is not in Engineering Backlog status, an error 

will be shown and the transition won’t be executed. 

In Development  Capabilities below this Epic can now be moved to In 

Development. 

Customer Review  A demo is attached as video to the Epic or scheduled as a 

meeting. The product team (the P1 TPM author, also known as 
stakeholder) reviews and approves or rejects the milestone. 
A stakeholder is limited with 48 hr SLA to perform review. 
After that the milestone will be approved automatically 

Release Pending  A validated milestone is waiting for deployment to production. 

Released  A validated milestone is deployed in production. 

The linked SPEC ticket is moved into Engineering Complete 

status. 

Cancelled  The milestone has been cancelled. 

9 
 Feature Project Delivery Framework 

Capability workflow 
A capability is represented in Jira with a Feature Story issue type. 

To Define  On this stage the capability is still undefined and  Anyone 

unapproved, so it cannot be picked for development. 
Only the product team (Jira PDM project role) can 
approve a “To Define” capability and move it to 
“Backlog”. 

Backlog  The capability is approved and defined enough to be  Product 

implementable: belongs to an approved L1 specification  Manager 
and has its own Definition of Done on the ticket 
description. 

In  An IC starts development of the capability on a feature  Feature SEM 

Development  branch.   Feature IC 

When the work starts on a capability, Feature SEM must 

make sure that QATestWriter team is informed, so Test 
Case writing can be ready for when the capability is send 
to next status. 

Ready For  Before sending to validation, IC needs to ensure code is  Product SEM 
Validation  according to QE technical guidelines.  (or Program 
Manager if 
A functionality proof is recorded and sent to product  available) 
team. 

Alternatively, feature branch is deployed to a 

development environment and validated there. 

There is a 24 hours SLA for the Product SEM to do this 

step. 

In Code  Once validated, a pull request from feature branch to  Product SEM 
Review  development branch is created.   Product CA 
QE team 
The Product SEM QE team will approve the pull request 
and move this issue to Reviewed. 

Reviewed  The Product CA will use this status to merge the pull  Product CA 
request to development branch, deploy to QA 
environment and run System Health Check. 

When all conditions are satisfied, the Product CA moves 

this ticket to next status.  

There is a 24 hours SLA for the Product CA to do this 

step. 

10 
 Feature Project Delivery Framework 

SLA - ‘Feature Defect Engineering On-Time’ 

Provider:​ Eng.Feature - FSEM / Feature Developer + PSEM / PCA + Eng.QAManualTester - 
QSEM / QA Engineer 

Precondition(s):​ a Feature Defect was found during Feature Story verification 

Starts:​ once a Feature Defect is created 

Process:​ Investigate a Defect. Then  

● Close it as invalid

or 

● Provide a fix, Review pull-request (if ok, move ticket to Reviewed), merge code to base
branch, build version, deploy it on QA Environment, verify the fix

Ends:​ once Feature Defect is rejected (the ticket moved to ‘Close’) or fix provided, reviewed, 
delivered to QA Environment and verified (the ticket moved to ‘Release Pending’) 

SLA time:​ 24 hours 

22