[Fiware-iot] FW: TR: Fwd: Detailed comments on the IoT Backlog information available on the Wiki/Tracker

Farkas, Lorant (NSN - HU/Budapest) lorant.farkas at nsn.com
Thu Nov 17 16:56:02 CET 2011


The promised examples on work items.
 
Br,
 
Lorant

________________________________

From: ext Juanjo Hierro [mailto:jhierro at tid.es] 
Sent: Monday, November 14, 2011 4:10 PM
To: thierry.nagellen at orange.com
Cc: Farkas, Lorant (NSN - HU/Budapest); jhierro >> "Juan J. Hierro"
Subject: Re: TR: [Fiware-iot] Fwd: Detailed comments on the IoT Backlog information available on the Wiki/Tracker




On 14/11/11 15:13, thierry.nagellen at orange.com wrote: 

	Hi Juanjo

	

	This point regarding Workitems is not clear to me.  You agreed during the last WPL/WPA telco that IoT is a bit late because of assets selection and standards analysis 

  Yes ...


	and that we have to delete all empty entries (in our case, typically User Stories) 

  Yes, I recommended to avoid sections linked to Features or UserStories, for example, where you simply had an empty list (a single empty bullet).



	and now you expect we create some WokrItems entries.

  Yes, what I expect to see is something in the backlog (either in the form of UserStory or WorkItem) that explain to me what you are going to do in the 1st Sprint.    Otherwise ... How could I answer the question about what does the IoT chapter team planning to get done by end of November ?


	

	

	As we explained that we will spend the next 10 days to describe the missing User Stories, do you want a WorkItems " describe user stories"? Or in another case do we have to describe the User Stories now ... and this is impossible.

  If you are simply going to work on refining identified Epic/Features that's fine.   Just want to know.   On the other hand, I envision that there are some WorkItems that would be nice to reflect like "Analyzing compatibility of the NGSI and OGC specifications for the Northbound APIs exposed to programmers" which give some more info and allow us to monitor progress.


	

	

	What do you expect exactly regarding WorkItems?

  To reflect any work to be done during the 1st sprint (that is, the period betwwen now and end of november) that would make sense to record and monitor beyond just "refinement of existing Epics/Features in order to identify Work Items and User Stories for the next sprint" (working on refinement of backlog entries doesn't need to be reflected in the form of backlog entries itself).

  A good example of Work Item (don't not if addressed in the first sprint or later) is the one I have mentioned regarding analysis of OGC and NGSI, but let me elaborate on another example of WorkItems and UserStories that may be helpful in describing how the Backlog may evolve ...   

  You may find out that we wish to support Features A, B and C for a given Generic Enabler that is part of the IoT Service Enablement Architecture.   For example, you may have a GE which is a kind of Directory, supporting three Features:


*	A=creation/deletion/modification of entries, 
	
*	B=discovery of entries that match some given criteria, 
	
*	C=ability to subscribe to events linked to creation/deletion/modification of entries in the Directory.   
	


  You may decide that such Features will be exposed through a well defined API.   Therefore, all the three Features may get refined into:


*	one single WorkItem M consisting in "Specifying a well-defined REST interface 'I' through which operations exposing features A and B are exposed", 
*	another WorkItem N consisting on "Extending specifications of interface 'I' to include operations supporting feature C", 
	
*	three UserStories O, P and Q corresponding to implementation of the operations in the REST interface 'I' exposing features A, B and C respectively. 


  Then, you may decide:


*	to address WorkItem M in Sprint X of the first minor release and then in Sprint X+1, also of the first minor release, you decide to address the implementation of UserStories O and P 
*	leave WorkItem N and UserStory Q to the second minor release of FI-WARE. 


  Note that in this example we are illustrating how Agile works differently than the traditional waterfall models: we are not waiting for finalizing the complete specification of interface 'I' to start implementing part of it.

  Does it make sense to you ?  Hope these examples help.

  If you believe so, don't hesitate to share with the rest of your team.

  Best regards,

-- Juanjo

  

  


	

	

	BR

	

	Thierry

	

	De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro
	Envoyé : lundi 14 novembre 2011 12:39
	À : fiware-iot at lists.fi-ware.eu
	Objet : [Fiware-iot] Fwd: Detailed comments on the IoT Backlog information available on the Wiki/Tracker

	

	Hi,
	
	  I forward the email I have just sent to both Thierry and Lorant to the FI-WARE Apps team so that they receive the comments as soon as possible and start to analyze them.   They should wait for your further instructions, overall regarding those issues for which they find that the action to be done is not that clear or too hard to implement.
	
	  Thanks,
	
	-- Juanjo
	
	
	-------- Original Message -------- 

Subject: 

Detailed comments on the IoT Backlog information available on the Wiki/Tracker

Date: 

Mon, 14 Nov 2011 12:36:01 +0100

From: 

Juanjo Hierro <jhierro at tid.es> <mailto:jhierro at tid.es> 

To: 

'Thierry.nagellen at orange-ftgroup.com' <Thierry.nagellen at orange-ftgroup.com> <mailto:Thierry.nagellen at orange-ftgroup.com> , Farkas, Lorant (NSN - HU/Budapest) <lorant.farkas at nsn.com> <mailto:lorant.farkas at nsn.com> 

CC: 

fiware-wpl at lists.fi-ware.eu <fiware-wpl at lists.fi-ware.eu> <mailto:fiware-wpl at lists.fi-ware.eu> , fiware-wpa at lists.fi-ware.eu <fiware-wpa at lists.fi-ware.eu> <mailto:fiware-wpa at lists.fi-ware.eu> 

	
	
	Dear Thierry and Lorant,
	
	  Here it is a list of issues I have identified in a more detailed revision of backlog entries, both on the Wiki and the tracker, linked to your chapter.  You have to review them and take the necessary corrective measure.   Despite I have marked the most critical ones in red, all of them are relevant and shall be addressed.  Many of the issues are rather easy to address.  With the exception of those market in blue, the rest of them might be solved before EOB today if responsibility to fix them is properly distributed and changes are implemented in parallel.   I remind you that sections on the Wiki should be edited in parallel (never clicking on the edit tab at the top of the page but clicking on the edit link at the right side of each section).
	
	  Please forward them to members of your team as soon as possible.
	
	  I copy the rest of the WPLs and WPAs because I haven't sent my detailed comments to all of them and it might be worth that they review your comments to find out what may apply to them as well.   This may help them to anticipate any issue on their respective chapters.
	
	  Best regards,
	
	-- Juanjo
	
	
	IoT Service Enablement:

	*	General comments: 

		*	It seems like there are contents on the Wiki that are replicated !!!   Please avoid duplication 
		*	You have capitalized all letters of the <backlog-entry-type> field in backlog entry Ids, that is, (EPIC, FEATURE, STORY) instead of (Epic, Feature, Story).   While not super-critical it leaves a bad impression and it would be better to fix it.  The issue here is that you would need to implement three changes: 1) rename the Wiki page each entry points to (this can be done using the "move" operation in the Wiki page) 2) change the name in the list of backlog entries in the "Materializing ..." page and 3) update the URL in the corresponding tickets in the tracker.   Not so hard if the task is distributed, otherwise is a bit painful. 
		*	Some entries linked to Features have a value assigned to the "FI-WARE Sprint Id" field which doesn't make sense.   The "FI-WARE Sprint Id" field should only be filled for user-stories or WorkItems. 

	*	IoT Communication/Connectivity Management: 

		*	Something strange happens with the entry identified as FIWARE.EPIC.IoT.ConnectivityManagement.DiscontinuousConnectivityManagement: It exists in the tracker but not on the Wiki ... The URL that is provided in the ticket works but navigates to a Wiki page that is not the one that you would expect. 
		*	What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ...   Note that in the case of WorkItems you won't need to create an entry on the Wiki. 

	*	IoT Communication/Service Control: 

		*	Something strange happens with the entry identified as FIWARE.EPIC.IoT.ServiceControl.NameResolution: It exists in the tracker but not on the Wiki ... The URL that is provided in the ticket works but navigates to a Wiki page that is not the one that you would expect. 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ...  I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Communication/Device FrontEnd: 

		*	The language used for describing goals in the template defined in August for backlog entries has not been followed in some of the backlog entries linked to this GE.   Some people may argue that description of goals doesn't follow the standard Agile conventions.   Such conventions try to emphasize what the users will get in terms of functionality. 
		*	There is a ticket on the tracker linked to a backlog entry with Id = FIWARE.EPIC.IoT.DevicesFrontEnd.NativeProtocol but I guess it should refer to FIWARE.Epic.IoT.DevicesFrontEnd.NativeProtocolAdapter.   The URL should also be fixed accordingly. 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Resource Management/Services and Resources Interaction: 

		*	There are some tickets on the tracker that do not follow the convention defined for the Id of the entry.   You have, for example, FIWARE.Userstory.IoT.ResourcesAndServicesDiscovery.DiscoverResource.Definition and "UserStory" should be "Story".  It is correct on the Wiki but not the tracker. 
		*	The language used for describing goals in the template defined in August for backlog entries has not been followed in some of the backlog entries linked to this GE.   Some people may argue that description of goals doesn't follow the standard Agile conventions.   Such conventions try to emphasize what the users will get in terms of functionality. 
		*	There are some inconsistencies between backlog entries on the tracker and on the Wiki.  Please align. 
		*	There is a value of "3" associated to the field "FI-WARE Sprint Id" for some entries linked to Features ... has no sense. 
		*	Are you sure that you are going to get all what you have labeled as "Story" and planned for the first FI-WARE Sprint finished by end of November ?   When planning a Story in the first Sprint ... Are you considering not just the specification of the final interfaces to be supported by the baseline asset or even its implementation?   If it was just the specification, probably you need to translate Stories into Features and then define a work-item linked to design/definition of the interface specifications that you can address in the first Sprint. 

	*	IoT Resource Management/Discovery and Resolution of Things: 

		*	The language used for describing goals in the template defined in August for backlog entries has not been followed in some of the backlog entries linked to this GE.   Some people may argue that description of goals doesn't follow the standard Agile conventions.   Such conventions try to emphasize what the users will get in terms of functionality. 
		*	There is a value of "3" associated to the field "FI-WARE Sprint Id" for some entries linked to Features ... has no sense. 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Process Automation/Template Handler 

		*	There is a ticket linked to a backlog entry referred as FIWARE.Epic.IoT.Exposure.ProcessRemoteExecution which doesn't have correspondence with anything on the Wiki 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Process Automation/Semantic 

		*	There is a ticket linked to a backlog entry referred as FIWARE.EPIC.IoT.Semantic.SemanticMediator which doesn't have correspondence with anything on the Wiki.  Apparently, it links to one Feature listed on the Wiki so seems like it's just a matter of labeling the entry as linked to a feature rather than an Epic. 
		*	There is a value of "3" associated to the field "FI-WARE Sprint Id" for some entries linked to Features ... has no sense. 
		*	The language used for describing goals in the template defined in August for backlog entries has not been followed in some of the backlog entries linked to this GE.   Some people may argue that description of goals doesn't follow the standard Agile conventions.   Such conventions try to emphasize what the users will get in terms of functionality. 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Process Automation/Exposure 

		*	There is a value of "3" associated to the field "FI-WARE Sprint Id" for some entries linked to Features ... has no sense. 
		*	Don't see ticket on the tracker linked to entry FIWARE.Epic.IoT.Exposure.ProcessRemoteExecution 
		*	Don't see ticket on the tracker linked to entry FIWARE.Feature.IoT.Exposure.ThingBasedQuery 
		*	Don't see ticket on the tracker linked to entry FIWARE.Feature.IoT.Exposure.AsynchronousThingBasedInteraction 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Data Handling/Local Storage 

		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Data Handling/Data Pooling 

		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Data Handling/Data Access Policy 

		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	*	IoT Data Handling/Data Handling 

		*	There is a value of "3" associated to the field "FI-WARE Sprint Id" for some entries linked to Features ... has no sense. 
		*	Don't see ticket on the tracker linked to entry FIWARE.Feature.IoT.DataHandling.EventsGenerator.M2mPlanet, FIWARE.Feature.IoT.DataHandling.EventsGenerator.Isis, FIWARE.Feature.IoT.DataHandling.EventsGenerator.Ngsi or FIWARE.Feature.IoT.DataHandling.EventsGenerator.EventTemplate.    
		*	The ticket linked to entry FIWARE.FEATURE.IoT.DataHandling.IoTSubscribe.Device seems to be duplicated on the tracker ... Maybe one should be linked to IoTPublish.Device ? 
		*	No User-Story or WorkItem has been identified ... What do you plan to do in the first Sprint (scheduled to finish by end of November) ?   Need to see some User-Stories or WorkItems planned ... I remind you that WorkItems do not require to create contents on the Wiki, only the tracker (this simplifies things a bit). 

	
	
	

________________________________

	Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
	This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
	http://www.tid.es/ES/PAGINAS/disclaimer.aspx


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20111117/2b0763c8/attachment.html>


More information about the Old-Fiware-iot mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy