We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
How to upload the full description of backlog entries to the Wiki - FIWARE Forge Wiki

How to upload the full description of backlog entries to the Wiki

From FIWARE Forge Wiki

Jump to: navigation, search

This tutorial describes how to add a new backlog entry to the Wiki.


Contents

Find the backlog page

On the Wiki Main page click on "Materializing the FI-WARE Vision" in the "Getting started with FI-WARE" section.



You will see the following page that containes different sections for each FI-Ware chapter (e.g. Apps & Services, Cloud Hosting, etc.). Use one of these sections if you are a FI-Ware member.


Create new entry in the list of backlog entries

When you navigate to the Wiki page where materialization of a given FI-WARE chapter is described, you will see it is structured in a number of sections, one per Generic Enabler on the chapter. Each section is further structured into subsections linked to Themes, Epics, Features and User-Stories. Select the proper subsection for your backlog entry to get positioned there. Then click on the "Edit" link on the right hand side of the subsection title in order to edit the subsection.



On the edit page for the subsection you have to add your backlog item in the list of backlog items.



 ATTENTION: Please follow the convention that has been defined for the Id field in FI-WARE Backlog entries. 


After adding a new list item you can save the page using the "Save page" to save the changed subsection. You will now see the complete page with a new item added in the respective subsection. This item link will be in red color, denoting that the page does not yet exist.



In order to create the page click on the red item link.

Insert the backlog entry template

A new editor page opens and you can start to enter your backlog entry description. Depending on the type of backlog entry you want to create, cut and paste one of the following texts into the editor window:

Feature Epic User story
{{Feature
|Name=
|Goal=
|Description=
|Version=
|Source=	
|Source contact=
|Stakeholder=
|Scope=	
|Theme=	
|Status=
|Priority=MST
|Relative priority=
|Chapter=
|Enabler=
|Rationale=
|Owner=
|Owner contact=
|Complexity=
}}
{{Epic
|Name=
|Goal=
|Description=
|Version=
|Source=	
|Source contact=
|Stakeholder=
|Scope=	
|Theme=	
|Status=
|Priority=MST
|Relative priority=
|Chapter=
|Enabler=
|Rationale=
|Owner=
|Owner contact=
|Complexity=
}}
{{User story
|Name=
|Goal=
|Description=
|Version=
|Source=	
|Source contact=
|Stakeholder=
|Scope=	
|Theme=	
|Status=
|Priority=MST
|Relative priority=
|Chapter=
|Enabler=
|Rationale=
|Owner=
|Owner contact=
|Complexity=
}}

Edit the backlog entry details

Fill in the details of the backlog entry. The following table describes how to fill the different fields of a backlog entry:

Field

ENUM

Description

Comments

Id

No

Used to uniquevocally identify the backlog entry

We will comply with the following format:

<backlog id>.<category>.<chapter>[.<GE name>].<name>

where:

  • <backlog id>::= "FIWARE"
  • <category>::= "Theme" | "Epic" | "Feature" | "Story"
  • <Generic Enabler name> is the Generic Enabler (GE) the backlog entry is associated to. If it is an Epic that is cross to several GEs, this field is omitted.
  • <chapter name> is the name of the FI-WARE project the backlog entry is associated to.
  • <entry name> is the value of the Name field of the entry, which should be a meaningful acronym.

Name

No

Descriptive name of the entry

This will be an acronym

Goal

No

Short phrase describing the goal for this entry

It should be formulated under a formula of the style:

  • "Applications (or Users, when dealing with end users) should be able to <perform some action> when <scenario> so that <description of derived results>"

or

  • "It should be possible to <perform some action> when <scenario>. As a consequence, <description of derived results>".

Version

No

Version associated to the entry. Helpful to monitor progress and follow-up modifications

We will use two digits, <x>.<y> where <x> changes when a major variation in the description holds. <y> will change as result of refining the description or value of some field.

Source

Yes

Project or organization who identified the use case / feature

 

Source contact

No

Contact point in Source project or organization (was "Author")

Contact point of the source

Stakeholder

Yes (per item in list)

List of additional projects or organizations interested in coverage of the use case / feature (the source is considered to be a stakeholder)

The value of this field may change over time

Scope

Yes

Could be:

  • "Platform" = it relates to a functional or non-functional feature required at platform level (not yet agreed whether "common" or "generic")
  • "Platform Generic" = It relates to a feature required at platform level and has been agreed is general purpose
  • "Platform Common" = It relates to a functional or non-functional feature required at platform level but whose applicability is restricted to applications in a few number of domains (Usage Areas)
  • "Application" = It relates to a user story related to some functional o non-functional feature required at application level
  • "Global" = It relates to some functional or non-functional feature required both at platform (generic or common) and application level
  • "Not Yet Determined" = when decision still has not taken place

The value of this field may change over time.


The value of this field is always “Platform Generic” for entries that are already part of the FI-WARE Backlog.


Regarding entries proposed by UC projects, they will always be initially assigned the "Platform" scope (these entries will be initially registered in the "requests for platform enablers" backlog).


Status

Yes

Could be:

  • "Pending" (still not revised)
  • "Planned" (is in the roadmap)
  • "Under execution" (being developed in current sprint)
  • "Done" (has been already developed)
  • "Deprecated" in which case the Description field should explain why and the list of Ids of entries replacing it when applicable.

 

MoSCoW priority

Yes

Could be:

  • "MUST" - Features that absolutely have to be done are categorized as Must. If any of these features are not done, the project will be considered a failure.
  • "SHOULD" - Features that are important to the success of the project, but are not absolute musts (they have a workaround or will not cause the project to fail) are categorized as Should.
  • "COULD" - Features that are nice to have but are not core features are categorized as Could.
  • "WONT" - Features that are not going to be implemented this time are marked as Won't.

In the first place, while "Owner" has not been identified, this priority will be assigned by the Source. Stakeholders may agree to change it. Final value will be assigned by the "Owner", although a new entry may be created, keeping the previous one for the sake of history (which would change to "Deprecated" status pointing to the new entry).

Clarification on WONT priority: Why should we have won’t features in the backlog? There are two reasons. One is that feature priorities can change as the project goes on. These features could have started as Should and been re-prioritized to Wont, and they may be re-prioritized back again. The second is that these features are a starting point to the second version.

Remember that features prioritized as “Must” should be only those features without which the project cannot be put into production, and will cause the project to fail. When you decide to mark a feature as “Must”, ask yourself if the project will have to be canceled if this feature is not implemented. Only if the answer is yes should you go ahead and prioritize it as Must.

Relative priority

No

Priority number relative to the same MoSCoW priority

In the first place, while "Owner" has not been identified, this priority will be assigned by the Source. Stakeholders may agree to change it. Final value will be assigned by the "Owner", although a new entry may be created, keeping the previous one for the sake of history (which would change to "Deprecated" status pointing to the new entry).

We may use maybe a number of 2 digits, with the first one linked to the MoSCoW priority and the second to the relative priority. That would allow to order entries just based on this number. Thus, we may have:

Priority 35 = "Should" with priority 5 among those labeled as "Should".

Value for this entry may not be assigned initially but entries will not be considered for planning in next sprint until they get a relative priority assigned.

Chapter

Yes

Will refer to chapters in FI-WARE, when dealing with entries related to FI-WARE GEs:

  • "Cloud"
  • "Data/Context"
  • "Apps"
  • "IoT"
  • "I2ND"
  • "Security"

When dealing with entries with "Application" scope, may contain value of chapters relevant to the application.

 

Enabler

No

Only applicable to Platform features. It identifies the Enabler to which this entry (feature) in the backlog applies.

 

Category

Yes

Would be "Theme", "Epic", “Feature” or "Story”


Description

No

Free text with all additional information that may be useful for final users to understand what functionality is provided. Explaining “how to demo” may be a good option here.


It may also include additional information that useful for the development team. In such case, the entry may contain URL links that are only accessible to members of the development team.


Rationale

No

Rationale of why the feature is needed

Should explain why the entry is relevant and has been assigned the MoSCoW priority.

Owner

Yes

Name of project taking care of it

Should be FI-WARE in the case of FI-WARE GEs

Owner contact

No

Name of person in Owner project taking care of it

May vary over time. In the case of FI-WARE, should be the link to the “FI-WARE General Support” tracker, that is:

https://forge.fi-ware.eu/tracker/?atid=162&group_id=7&func=browse

Complexity

Yes

Number describing how complex supporting the use case / feature will be. Will map to the following categories:

  • "XXL": Costs quite a lot
  • "XL": Costs a lot
  • "L": Has a significant cost
  • "M": Medium cost
  • "S": Doesn't take that much
  • "XS": It's almost trivial

 


Additionally, you might have a look at existing backlog entries for reference:

{{Epic
|Name=Manage stores & offers
|Goal= A market place can handle offers from multiple stores.
|Description= A store can be registered at the marketplace. The market place maintains a list of active stores. The marketplace can receive a list of offerings from different stores. The store can trigger an update of the offerings at the marketplace.
|Version= 1.0
|Source=[[SAP AG]]	
|Source contact=[[Torsten Leidig]]
|Stakeholder= [[Ericsson]]
|Scope=[[Platform Common]]
|Theme=[[Theme:Aggregator creates mashup]]
|Status=Pending
|Priority=MUST
|Relative priority= 5
|Chapter=Apps
|Enabler=[[Marketplace]]
|Rationale=	
|Owner=[[SAP AG]]
|Owner contact=[[Torsten Leidig]]
|Complexity= XL
}}


After completing the descrption, press "Save page" and the newbBacklog entry is created and displayed.

Personal tools
Create a book