Agile Tracker Approach Discussion
Issues regarding the development methodologies and project management techniques are discussed in this thread. The "style" for this project will be formalized in project documents (or simply refer to ones adopted from other projects) as the team reaches an agreement.This thread contains discussions of the process.
I have a basic structure set up in Jira using the Agile and Jira features. Brad just reviewed with me so we are in good enough shape to be adding cards. There is more work to expecially in automating the addition of priorities and getting good reports from metrics but this should not affect our ability to add cards.
57:25 PM Daniel W. Davis: It would be nice to add cards, written in a function way not a component or implementation way, for any part of the project. Still its good to concentrate on near term cards.
58:47 PM Daniel W. Davis: I have added four iterations and there is likely time for a fifth. If you are using the Planning or Task board to add cards please pay attention to the drop down for the iteration.
59:19 PM Daniel W. Davis: Iteration 1 has items scheduled. The rest of the cards can go in "unscheduled" for now.
00:21 PM Daniel W. Davis: I am using the "addresses" and "is addressed by" links to tie stories to epics (to help Jonathan to drill down.
00:44 PM Daniel W. Davis: There is a new plug-in called "Structure" that we can talk about later.
02:31 PM Daniel W. Davis: Brad and I discussed a starting point that work can be done directly from a "Story" or if the story needs additional information or to be broken into bite sizes its perfectly OK to add other types of Jira issues, tied to the story.
04:30 PM Daniel W. Davis: We hope the stories are kept small, 8 story points or less so we can get a reasonable velocity during the iteration. Anything can be a story, function, investigation, meeting. Just preferrably not expressed in implementation language.
04:39 PM Daniel W. Davis: Go ahead Chris.
04:56 PM Daniel W. Davis: I will be summarizing this on a Wiki page too.
08:40 PM Chris Wilper: Just learning a bit about the Planning Board and browsing around a bit. Something you said made me wonder, though: "It would be nice to add cards in a function way and not a component or implementation way". Can you give an example of each? I'm not sure I understand. I feel that eventually, it would be good to track work in terms of concrete deliverables and it's hard to avoid talking about individual components when doing that.
09:30 PM Daniel W. Davis: I rewrote some of the cards that way.
09:42 PM Daniel W. Davis: One second.
11:11 PM Daniel W. Davis: For example, DFR-1 is now a story.
11:30 PM Daniel W. Davis: It says: Investigate how to take input files and create a richer experience of the content for researchers and other users.
12:01 PM Daniel W. Davis: It does not says: Investigate how to build the Object Creation Service.
13:37 PM Daniel W. Davis: However, when we have an Object Creation Service a story could say: We need to ba able to characterize incoming files.
16:39 PM Chris Wilper: Ok, right. So I think what you mean is that stories shouldn't talk about components, but more about functional capabilities of the system. That makes perfect sense. However, some "cards" (issues) might be more impl-specific, correct?
17:48 PM Daniel W. Davis: The cards should be understandable to less technical users but we keep in mind the system we are implementing.
18:23 PM Daniel W. Davis: Especially in big chunch, like GUI.
19:35 PM Daniel W. Davis: We are free to be as technical as we want in adding Jira issues to implement the card (or on a story card description if is pretty understandable).
21:45 PM Chris Wilper: Ok, I know greenhopper has "Add a new Card", but AFAIK, that's just a general term for a JIRA issue, whether it's an epic, story, bug, etc.. So what it sounded like you were saying is that all issues (high and low-level) should be written at a high level.
22:43 PM Daniel W. Davis: Not at all. We can do work from any type of Jira issue.
24:34 PM Daniel W. Davis: But if we are adding an Epic or Story "issue" it is suggested by most of the agile gurus that we do it in user-oriented language most often functional.
25:09 PM Daniel W. Davis: And that our time estimates for new additions be against stories in story points.
25:24 PM Daniel W. Davis: That is new functionality.
26:09 PM Daniel W. Davis: So regular Jira does not go away.
27:06 PM Chris Wilper: Also, should we have a "Feature" issue type? I don't see it yet but I thought we had talked about tracking lower level stuff using that type of issue, if needed.
28:21 PM Daniel W. Davis: You are right in that "function" and "feature" have similar semantics. This discussion is a suggestion but it is the group that will decide the process.
29:11 PM Daniel W. Davis: But in many ways the technical Jira issues shorten to task, bug, and documentation.
29:43 PM Daniel W. Davis: Why duplicate function and feature (but it would be nice to have an example).
30:48 PM Daniel W. Davis: The newer agile methods seem to think that describing features in a technical way excludes the user and overly ties it to an existing component or design.
31:14 PM Daniel W. Davis: The idea of stories to make it easier to talk to users.
31:36 PM Daniel W. Davis: Or product owners.
33:02 PM Daniel W. Davis: Listening to Carissa's and some of Michelles feedback on DuraCloud is often couched in story-like language when getting comments from users.
38:03 PM Daniel W. Davis: Chris: In the end this "style" for using Jira is a strawman. Trying to keep it simple but useful for both Jonathan/Michelle and the development team. I figure this startup of the first iteration is where we work this out.
39:28 PM Daniel W. Davis: It seemed that exactly following DuraClouds approach did not help feed non-technical community as well so this proposal is a slight variation. Researchers are likely going to be a tough sell.
39:50 PM Daniel W. Davis: BTW: One on the goals for Monday is to add a SWAG in story points against the current Epics. We know very little but he needs a budget.
43:10 PM Bill Branan: It seems like the plan is to use the DfR jira for the same kinds of technical jira items that we do in DuraCloud/Fedora, but to also use the same jira project to manage higher level stories which have historically been captured in other places (like the wiki) for projects like DuraCloud and Fedora
44:15 PM Daniel W. Davis: Bill: And in a maintainable tie them together for trackability. It straight our of the latest agile books.
44:52 PM Daniel W. Davis: Bill: This way we avoid using something like Contour for capturing Use Cases and Requirements.
2:45:45 PM Daniel W. Davis: That's JAMA Contour if you care to glance.
46:08 PM Chris Wilper: I appreciate the value of tracking things at the story level. But I think some sort of ability to break things down into technical deliverables would be good too. So I think we need to have some agreement on what that is. Should be add Task issues and link them to stories, or should we just "Create sub-task" on the Story?
46:28 PM Daniel W. Davis: Chris: For sure.
47:07 PM Bill Branan: I'm inclined to stay away from sub-tasks, they seem limiting
47:17 PM Daniel W. Davis: I was thinking to create the Task in Jira and link it to the story.
47:42 PM Daniel W. Davis: But only create sub-tasks if needed.
47:59 PM Daniel W. Davis: We can link several Jira tasks to one story.
48:17 PM Chris Wilper: Yeah I recall using sub-tasks in Fedora a bit and they were kind of a pain. Linking seems more flexible.
48:40 PM Daniel W. Davis: We can even link issues of any sort even track in DuraCloud (to aid DfR stories).
49:17 PM Bill Branan: So the question becomes, which issue types, in particular, do we need to pull in to the DfR project
49:38 PM Daniel W. Davis: The good things about sub-tasks is that they are kept together and time accounting is automatically rolled up.
50:02 PM Daniel W. Davis: If we keep the stories small (less that 8 point) we can track velocity not time.
50:29 PM Chris Wilper: If we agree on doing Task issues and linking them to stories, then I only see that we're lacking Tasks.
50:38 PM Daniel W. Davis: So no time keeping on Jira tasks either the story is done or its not.
51:11 PM Daniel W. Davis: Really. I though tasks were a built in Jira issue type. Gotta look.
51:45 PM Bill Branan: Task is an existing issue type in Jira, just not part of the DfR project
52:00 PM Daniel W. Davis: Yep, tasks are not in the profile but they are supporting in Jira.
52:19 PM Bill Branan: We already have the Bug type included
52:32 PM Daniel W. Davis: Right now the profile does not include feature either.
52:46 PM Daniel W. Davis: I suggest using one or the other to keep it simple.
52:49 PM Bill Branan: The issue type being: New Feature
53:04 PM Bill Branan: There is also: Improvement
53:15 PM Bill Branan: and: Code Task
54:03 PM Daniel W. Davis: They are not in the DfR profile so we should add what is most appealing.
54:48 PM Bill Branan: In DuraCloud we tend to use:
Bug - for bugs
New Feature - for completely new functionality
Improvement - for updates to existing functionality
Task - for non-code-related activities
55:09 PM Daniel W. Davis: I don't think we need to be that fine grained in our semantics.
56:00 PM Daniel W. Davis: Just bugs, documents and a generic type that means we a implementing a story.
56:19 PM Chris Wilper: I don't think we need feature personally. Stories seem to encapsulate them at the right level (though one software "feature" might consist of several stories). Also, I'm not sure Improvement or Code Task really adds much value...I'd favor keeping it simple and just having "Task" as a generic way to break work down, whether it was related to a Story of a Bug, and not required in either case.
57:35 PM Bill Branan: I'm fine with simplifying. Sounds like we're narrowing to these issue types: Epic, Story, Documentation, Bug, Task
58:37 PM Bill Branan: Task being the only one that we need to pull into the DfR project
59:21 PM Bill Branan: we can also consider pushing out issue type: Technical Task, just to avoid confusion
59:22 PM Daniel W. Davis: We can alway add more types later if it helps us manage the project.
59:37 PM bradley.mclean: +1
00:46 PM Daniel W. Davis: Even though we are missing Andrew are we cool for now?
02:36 PM Chris Wilper: "Qui tacet consentit" (silence implies consent...even when moving across the country) 
03:47 PM Daniel W. Davis: I'll stripe the conversation out to the Wiki and, when time permits, clean it up document the style (free to change when the team wills it so).
Bill Branan
Chris Wilper
