Agile Plugin

The goal of the AgilePlugin? is to provide additional Trac support for,

Milestones

These could be the same as a Ticket milestones. Regardless compatibility with Ticket milestones is required. However Milestone might be augmented to include two additional pieces of information: the reason for the Milestone (objectives) and the main deliverable goals (key feature summary). For example, the reason a a milestone might be to provide a demo-able release of a new product highlighting the potential capabilities. The main deliverable goals could be to provide a working interface through a known middle-ware component and also allow ODBC access to a specific type of captured data.

In addition we need a way to have ordering between milestones which does not rely on alphabetical ordering or date ordering. This could simply de a depends_on field which enumerates all the existing milestones. This will allow us to discover and insert new milestones. If a dates are assigned to milestones then the default display of the basic Trac could be used.

UseCases?

Use Cases can be seen as a toll for multi-level representation of the project's capabilities. Specifically a set of high level use cases might be used to help strategic planning within the company while more detailed use cases can be used to allow the development of User Acceptance Text plans.

So how then, do Use Cases relate to User Stories? Well in some cases we can think of User Stories as being a Use Case (Brief) at a particular level of detail. This is true, however in order to have a more precise differentiation of Use Cases from User Stories we should focus not on what the Use Cases and User Stories say, but on how they are used.

In the case of User Stories we can think of them as units of work that provides value to a User. The primary purpose of a User Story is to identify piece of functionality that has value for a user and also has associated with it a relative sizing representing the work required to provide that functionality along with a note of other User Stories that this User Story depends on.

If Use Cases and User Stories existed on 2 dimensional plane we would have something like this,

High Level       UseCase01 (split)            UseCase05       UseCase16
                    / \                          |               |
                   /   \                         |               |
          UseCase03     UseCase24    UseCase18   |    UseCase07  |   UseCase45    UseCase21
              |             |            |       |       |       |      |            |         
              |             |            |       |       |       |      |            |
WORK   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
40       UserStory02              UserStory54         UserStory29          UserStory74          
20          UserStory98     UserStory34       UserStory73         UserStory08   
       = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
13                     UserStory23                            UserStory79          
 8       UserStory55                                     UserStory86          UserStory47
 5                 UserStory52            UserStory28
 3                            UserStory64                       UserStory09          
       = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
WORK   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
           |             |       |       |               |              |            |            
           |             |       |       |               |              |            |         
Test    UseCase78     UseCase62  |    UseCase16       UseCase84      UseCase36    UseCase37
Level      \                     |                                      \
            \                    |                                       \
         UseCase45            UseCase50                               UseCase11

What this diagram is trying to show is that we have basically three levels at which we can describe the product.

  • Use Case Briefs We have the high level Use Cases which may encompass more 0 or more User Stories. These Use Cases can help describe at a high level what will be delivered. To see exactly what will be delivered the User Stories must be consulted.
  • User Stories We have the middle level which are relatively sized User Stories. These are potential work items that can be scheduled for implementation to allow the goal in context of the User Story to be satisfied.
    • Within this level we have User Stories that are small enough to be targeted for work in an iteration. These are stories below a given size as indicated.
  • Use Cases Finally we have a lower level of Use Cases that detail a specific success scenarios that may be relevant to 1 or more User Stories. The step-by-step nature of these Use Cases makes them particularly suitable as a basis for the development of User Acceptance Test Plans.

UserStories?

Note that it should be possible to raise Tickets against UserStories?. See also the note about Tasks below.

Initial Schema Considerations

A basic schema for a UserStory? plugin would consist of,

  • Id
  • Story
    • This is equivalent to the Title in a Trac ticket, however we would want to display users in the Story as a wikified links.
  • Description
    • This could point to a wiki page like the blog plugin, OR create it's own idea of a wiki page. The point is we will update this page regularly, unlike the approach taken for a ticket.
  • Completed Level For Done (only if six state model is used)
    • If the six state model is used (see below) then this field's value will be one of, 'Test Complete' or 'Done'.
  • Size
    • This would be a reference to a size row in the Size table which contains a Value:Description pair. This allows us to predefine a list of allowable sizes and also provide friendly descriptions of what the sizes mean.
    • If the six state model is adopted (see below) then it makes sense to have three team specified sizes, Test Complete Size, Doc Complete Size and QA Complete Size. These would automatically be summed to give a total Size or a Done Size. If the Completed Level For Done was 'Test Complete' then the Done Size would simply equal the Test Complete Size. In this case both Doc Complete Size and QA Complete Size would be 0.
  • Milestone
    • This could be the same as a Ticket milestone. Regardless compatibility with Ticket milestones is required. However Milestone might be augmented to include two additional pieces of information: the reason for the Milestone (objectives) and the main deliverable goals (key feature summary). For example, the reason a a milestone might be to provide a demo-able release of a new product highlighting the potential capabilities. The main deliverable goals could be to provide a working interface through a known middle-ware component and also allow ODBC access to a specific type of captured data.
  • Status
    • A UserStory? can be in one of four states: Split (Inactive), Not Yet Started, Started (Open, Allocated to an Iteration), Done (can be Reopened to the Open state).
    • OR
    • A UserStory? can be in one of six states: Split (Inactive), Not Yet Started, Started (Open, Allocated to an Iteration), Test Complete (can be Reopened to the Open state), Doc Complete (can be reopened to the Open state), Done (Acceptance Complete - can be reopened to the Open state, Test Complete state). Supporting these additional states allows for more visible hand-off of a UserStory? to the next team member who needs to continue advancing the state towards 'Done'.
  • Completed_In_Iteration
  • OR
  • Started_In_Iteration
  • Test_Complete_In_Iteration
  • Doc_Complete_In_Iteration
  • Done_In_Iteration
    • Setting 'Done_In_Iteration' (Acceptance Complete) without setting either 'Test_Complete_In_Iteration' or 'Doc_Complete_In_Iteration' will result in those fields automatically being set to the same value. It should be possible to not expose these fields at all if that is desired. For example if you do not want to support separate completion of doc and QA.
    • We might want to be able to track this information more accurately for historical purposes. Since this will be automatically generated this should should come for free. Particaulary we would like to associate an open and close iteration for each state.
  • Split_From
    • A non-zero Split_From field indicates that this story was split from another (presumably larger) UserStory?. This could take the form of the split UserStory?'s id or a string value from a Split_UserStory table (with a row added when a story is split). Regardless of the method of storing this information two pieces of information will be displayed. The 'Id' of the split UserStory? and the 'Story' (Title) of the split UserStory?.
  • Tags
    • This would be equivalent to the 'keywords' field of a ticket.
  • Multiple_Component_List
    • The assumption is that a UserStory? could belong to 0 or more 'components' of the project. This could be represented simplistically as a could comma separated list, chosen from predefined list, or as a separate list from ticket components but inclusive of but possibly inclusive of the ticket components. The concern is that there may be more components available to UserStories? than are available to tickets as tickets are presumably externally facing.
  • Depends_On
    • A UserStory? can depend on 0 or more other UserStories?. This information, along with the Graphviz plugin, can be leveraged to display dependency graphs of UserStories?.
  • Done Criteria
    • A statement of what completing this user story means. This can be empty so long as the User Story is not associated with an Iteration.
  • Users
    • Extrapolated from the Story field this allows grouping of UserStories? based on the Users associated with them.

More thoughts on User Stories

  • Milestone
  • Split_Status - can be one of Split, Active
  • Size - can be one of undefined (-1 or some default like 13, 20, 40 or 100), not needed (0), 1, 3, 5, 8, 13, 20, 40, 100. From the sizes we can infer whether we need Doc or Acceptance testing.
    • Test_Complete_Size
    • Doc_Complete_Size
    • Acceptance_Complete_Size
  • Started_In_Iteration - 0 or Iteration Id
  • Test_Complete_In_Iteration - 0 or Iteration Id
  • Doc_Complete_In_Iteration - 0 or Iteration Id
  • Acceptance_Complete_In_Iteration - 0 or Iteration Id
  • Depends_on_Stories - Empty string or comma separated list of Story Ids

Some simple examples

  • 27 : Id
  • Enduser can do stuff : User_Story (Title)
  • BlahBlah? : Description (wiki page)
  • 40 : Size (Value:Description)
  • R1 : Milestone
  • Split : Status ( Active, Split, Complete )
  • 0 : Split_From(Splitted_Id:User_Story->Title)
  • Tags
  • Multiple Component List (could comma separated list, chosen from predefined list - separate list from ticket components but inclusive of)
  • Depends_On (0 or more other User_Stories)
  • 234 : Id
  • Enduser can do more specific stuff : User_Story (Title)
  • BlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlah? : Description (wiki page)
  • 13 : Size (Value:Description)
  • R1 : Milestone
  • Active : Status ( Active, Split, Complete )
  • 27 : Split_From(Splitted_Id:User_Story->Title)
  • Tags
  • Multiple Component List (could comma separated list, chosen from predefined list - separate list from ticket components but inclusive of)
  • Depends_On (0 or more other User_Stories)

Iterations

Initial Schema Considerations

An Iteration should consist of,

Tasks

Adding time tracked Tasks to Trac should be consistent for both UserStories? and Tickets. This would allow tackling of Tickets (possibly as overhead items for an iteration) and UserStories? consistently within an Iteration. Is it possible to provide an optional Time tracking interface to a Trac ticket and achieve the same thing? That should be explored.

Initial Schema Considerations

A Task should consist of,

  • Work_Item (that names sucks... we need something generic that doesn't sound like a punishment)
    • A Task is associated with either a UserStory? or a Ticket.
  • Effort_Estimate
    • This would be an Initial Time Estimate, or effort estimate of the Task mainly for the purpose of successful IterationPlanning?.
  • Status or Complete
    • If 'Status' is used then the status can be one of NotComplete? or Complete. From the UserStory? perspective Tasks are binary artifacts. However we can also track time (or effort) against Tasks using the other time related Task fields below.
  • Time_Segments
    • Ideally we will a 0 or more Time Segments associated with a Task. These capture time or effort marked against the task. How this interface is exposed could be customisable so that it is possible to have a simpler 'time-elapsed' interface.

Notes on time tracking aspects of tasks

Time tracking should be optional. It should be possible to simply treat tasks as binary artifacts so this should be an option. Some will want to use the time tracking facility for time sheet tracking or simply as a sanity check. This could be somewhat complicated so therefore we might want to initially stage this feature as follows,

  • stage 1 Notes (link to Xplanner)
  • stage 2 Current Time Elapsed
  • stage 3 Time Segments

Iteration Notes

Task Notes

  • Effort_Estimate (Initial Time Estimate)
  • Status (NotComplete?, Complete)

  • reference one of
    • User Story
    • Ticket

stage 1

  • Notes (link to Xplanner)

stage 2

  • Current Time Elapsed

stage 3 (like xplanner)

  • Time Segments

User Stories

First Attempt

  • Id
  • User_Story (Title)
  • Description (wiki page)
  • Size (Value:Description)
  • Milestone
  • Status ( Active, Split, Complete )
  • Completed_In_Iteration ( 0 or an Iteration Id )
  • Split_From(Splitted_Id:User_Story->Title)
  • Tags
  • Multiple_Component_List (could comma separated list, chosen from predefined list - separate list from ticket components but inclusive of)
  • Depends_On (0 or more other User_Stories)

  • 27 : Id
  • Enduse can do stuff : User_Story (Title)
  • Blah : Description (wiki page)
  • 40 : Size (Value:Description)
  • R1 : Milestone
  • Split : Status ( Active, Split, Complete )
  • 0 : Split_From(Splitted_Id:User_Story->Title)
  • Tags
  • Multiple Component List (could comma separated list, chosen from predefined list - separate list from ticket components but inclusive of)
  • Depends_On (0 or more other User_Stories)
  • 234 : Id
  • Enduse can do more specific stuff : User_Story (Title)
  • Blah : Description (wiki page)
  • 13 : Size (Value:Description)
  • R1 : Milestone
  • Active : Status ( Active, Split, Complete )
  • 27 : Split_From(Splitted_Id:User_Story->Title)
  • Tags
  • Multiple Component List (could comma separated list, chosen from predefined list - separate list from ticket components but inclusive of)
  • Depends_On (0 or more other User_Stories)

Should Stories have a Topic tags that can have issues against them?

For example let's assume we have a new issue come in. Should we allow it to be assigned against a Topic instead of a story directly? This may be a better option than allowing assignment against a Milestone. By default Topics would appear in the undefined Milestone.

Implementation Questions

How should we implement this? What is the simplest set of changes that we can make that allow us to use Stories and Use Cases?

  • One thought is to write a modified Ticket System that handles User Stories instead of Tickets.
  • Another idea would be to modify the ticket system so that tickets could only be raised against something, for example. A ticket could only be raised against a User Story, or Topic or other artifact, but NOT against a Milestone directly. This would allow the Roadmap page to be composed from a more detailed set of data. The indirection level between the Ticket and Milestone would be responsible for associating the Milestone. The association would happen on the individual User Story page.
    • If we could identify a name for the thing that a ticket is assigned against then we would simply need to make a User Story a kind of thing. Perhaps we should refer to this as a Requirement, Need, Feature, Artifact, Element, Promise, UserStory?, Expectation, ValueItem?, Unit, InchPebble?, Topic, IssueTarget? (need to think over this more). The point is we might like to support the idea of being able to assign a Ticket against something other than a User Story, which is perhaps only one type of IssueTarget?. An IssueTarget? would have associated with it a Milestone. We would then use the state of the IssueTarget? to determine the Roadmap.