Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Story for the Teaser Demo #8

Open
stonier opened this issue Apr 1, 2014 · 7 comments
Open

User Story for the Teaser Demo #8

stonier opened this issue Apr 1, 2014 · 7 comments
Assignees

Comments

@stonier
Copy link
Member

stonier commented Apr 1, 2014

Work on a 'big picture' user story/scenario for the teaser demo.
Think about the story you will tell to the project review committee when you're showing the demo.
This will allow to guide the development of the teaser until then

The user story should be concrete with details on what needs to be done and what each user sees during the demo, for example: “Dorothy wants to add donuts to the service delivery. She goes into the ideation UI and starts a new 'project' ..."

@adamantivm
Copy link

@hughie did you get any chance to think about this?

One aspect that I find particularly important to understand is some concrete details about which parts of the process are specific to robotics and/or to rocon. I think it will be very important to have at least one example of that in the form of a story that we can demo to the reviewers.

@hughie
Copy link
Member

hughie commented Apr 8, 2014

@adamantivm Yes, now I'm working for this. I'll update and we can talk about it on tonight.

@hughie
Copy link
Member

hughie commented Apr 8, 2014

@adamantivm
Copy link

I like the user story, I think it's a good start.

With respect to how the data model interacts with it, I would say in general it's OK, but I can see a couple of things that will be important / interesting:

  1. In the user story, it would be interesting to think in terms of which "output" is required on each step. For example: "idea", "business model", "UI design", "specification", etc. I think these would match to the different "Work Item" types in the model

  2. I realize that there may be multiple Work Item types that go in the same perspective. Furthermore, it will be interesting to make the "type-specific fields" we put on each Work Item as similar as possible for Work Item types that use the same perspective.

  3. I think we also need a "related Work Items" field on each Work Item, that is used to track which Work Item is related, or was used to create a new one. Maybe this is similar to @hughie's idea of hierarchy (parent Work Item). One suggestion to make it general is to make "related" with a "type of relationship" (parent, linked, reference, etc.)

@hughie can you tell me what you think? based on your comments I will update the data model diagram to match.

@hughie
Copy link
Member

hughie commented Apr 9, 2014

Thank you Julian, I hope Cento can be a expert for realizing ROCON solution from idea. It is guiding what is next step and showing what you did for this goal.

  1. In the user story, it would be interesting to think in terms of which "output" is required on each step. For example: "idea", "business model", "UI design", "specification", etc. I think these would match to the different "Work Item" types in the model

Actually, I thought "Work item" was just "Item". because, "Item" can be anything. "type"of "item" is specifying what kind of item like [ idea, user story, task, issues ...]. If the type is "task", then It can have "result" in type-specific filed. If we think everything is work then, It is "Work item" and It has "type" for setting a result for this "Work item". I don't know which way is better yet. How do you think about this?

  1. I realize that there may be multiple Work Item types that go in the same perspective. Furthermore, it will be interesting to make the "type-specific fields" we put on each Work Item as similar as possible for Work Item types that use the same perspective.

We can suggest to default types of work item. In my opinion the type and type specific fields should be configured by user. Otherwise user can think it is not necessary step.

  1. I think we also need a "related Work Items" field on each Work Item, that is used to track which Work Item is related, or was used to create a new one. Maybe this is similar to @hughie's idea of hierarchy (parent Work Item). One suggestion to make it general is to make "related" with a "type of relationship" (parent, linked, reference, etc.)

I agree. I think this is most important. I want to make user can make "Item" anywhere. User can see the item in the perspective. also, they can see it's relation in project management view for supporting traceability. (I.E [idea]-[epic user story]-[user story level1]-[user story level2]-[Task]-[Result]-[Feedback]). I wanna see why do we make this result from idea.

@adamantivm I'm not sure about I wrote down my thinking properly, If some points are not clear, please let me know. I'll try again.

@adamantivm
Copy link

@hughie thank you very much for your comments. I understand everything you said.

  1. In the user story, it would be interesting to think in terms of which "output" is required on each step. For example: "idea", "business model", "UI design", "specification", etc. I think these would match to the different "Work Item" types in the model

Actually, I thought "Work item" was just "Item". because, "Item" can be anything. "type"of "item" is specifying what kind of item like [ idea, user story, task, issues ...]. If the type is "task", then It can have "result" in type-specific filed. If we think everything is work then, It is "Work item" and It has "type" for setting a result for this "Work item". I don't know which way is better yet. How do you think about this?

I lean more towards the second option: "Work Item" with a type for setting the result type. Can you please describe some examples of "Item" that doesn't have a result?

For the rest of your comments, I agree with everything. I also understand your point about traceability (i.e.: why do we make this result from idea) and I think we can do it with "related" and "type of relationship".

Please let me know what you think about "Work Item" and I will update the data model.

@hughie
Copy link
Member

hughie commented Apr 10, 2014

I lean more towards the second option: "Work Item" with a type for setting the result type. Can you please describe some examples of "Item" that doesn't have a result?

When I see this question, I tried to think which "item" doesn't have a result?
idea? issue? Actually, every type can have result.
Oops, everything is work. It's sad reality.
It's just kidding. I could not find the examples of "Item" that doesn't have a result. So, I'm fine for using "Work Item".

I'm getting off the subject here, but when I surveyed for Cento. I found Gamification concept. After sometime, I'm trying to apply this concept into Cento. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants