How to handle hangover tasks?

Follow

Comments

10 comments

  • Avatar
    Tim Vold

    Chris,


    Apologies for not getting back to this until now - dev. cycles, etc.


    Yes, the extended structure is:  Release -> Iteration -> Story -> Spike -> Task


    I understand that your Iterations may span Release.  For us, a Release is comprised of multiple two week Iterations.  The entities that may span releases are Epics:  Epic -> Feature -> Story(ies)


    Note: Our Features don't span releases.


    To your point about "rate of change" below, I have two charts similar to yours: the first is cumulative and the second is not.  That second chart shows me the ebbs and flows of scope, dev. complete, story acceptance, QA complete, etc. over the Iterations of a release.  It took me a bit of time the first go to understand what it was telling me - at first glance it looked like a mess.  Now, it is more predictive than the cumulative chart.  And as I've made adjustments to the process, the hills and valleys have smoothed out - it's a more even burn.


    Regards,


    Tim

  • Avatar
    Michael Decleene

    I think I'm following you.  If you're tracking something like a "task complete iteration," I believe what you're looking to do is sum estimates on all tasks for stories in this iteration, EXCEPT for tasks that were actually completed last iteration.  If so, I believe this would be as simple as adding a WHERE clause to your select statement that produces your black line.


    Instead of:


          data: SELECT 'Reporting - Added to Iteration', SUM('Work - Estimate')


    do something like:


          data: SELECT 'Reporting - Added to Iteration', SUM('Work - Estimate') WHERE 'Iteration Task Complete' > ('Current Iteration')


    Edit: Hmm...Not sure if this will include tasks where "Iteration Task Complete" is NULL.  If not, alternate syntax would be "Where Iteration Complete NOT < Current Iteration", though I'm not sure if "Not <" is valid syntax.  Sorry--away from my Mingle instance today...

  • Avatar
    Chris Leon

    Tim, thanks for that explanation. 


    Could you clear one thing about your structure up for me, your release tree doesn't actually have Story in it: Release -> Subrelease -> Iteration?  And then stories are related to iterations based on those card properties you mentioned?


    We've got it set up right now to have Release -> Story and Iteration -> Story -> Task, because we don't think of iterations as wholy enclosed by releases.  But I can see that if Iteration wasn't a parent of story, but associated in the way that you do, hangover is not a problem.

  • Avatar
    Chris Leon

    I was actually thinking something along the lines of


        WHERE 'Iteration Task Complete' == (Current Iteration) OR 'Iteration Task Complete' == NULL


    although mainly that's because I assumed that < wouldn't work for cards.  If it does, what does it do it on, card number?

  • Avatar
    Tim Vold

    Chris,


    We often have Stories or Spikes that unintentionally span multiple interations.  Any stories, spikes, tasks that are incomplete at the end of IterationX get moved to IterationY (the next iteration).  If we are at the end of the dev. cycle (eg. have to QA in prep for deployment to Prod) we return any uncompleted stories, spikes, tasks, etc. to the backlog.


    For burn-up, burn-down, velocity tracking, we track via transitions which Iteration a card was Added, Analysis Complete, Scheduled for Dev., Dev. Complete, Scheduled for QA, QA Complete, and Deployed.


    Thus, if Story ABC was Scheduled for Dev. in Iteration 2; but development didn't complete it until Iteration 3, we see that in our tracking charts and graphs.


    An example of my mingle project looks like:


       project XYZ



    • Release xyz.1

      • Release xyz.1.1

        • Iteration 1

        • Iteration 2

        • Iteration 3

        • Iteration 4



      • Release xyz.1.2

        • Iteration 1

        • Iteration 2

        • Iteration 3

        • Iteration 4





    • Release xyz.2


    I hope that helps.


    Regards,


    Tim

  • Avatar
    Michael Decleene

    I'd ask specfically what you're trying to report on, and what the tracking is that breaks.


    In the way I'm most familiar with doing Agile, there's no "partial credit" for incomplete stories--you claim the story points when the story is complete.  If a 4 point story is about halfway done at the end of the iteration, you don't claim 2 points in iteration X and 2 points in iteration X+1.


    Task tracking (again, in the way I usually do things) is a different beast.  When tracking hours by task, you keep track of actuals.  You don't necessarilly worry that the sum of the task hours is the same as the story point estimate on the story (though you can track that if you want to).  It's important to keep the concepts separate if you're trying to track velocity--if you have 50 estimated story points on the backlog, you don't want to re-estimate everything when you do the task breakdown or you can lose predictability.


    If you're tracking story points separately from task estimates, you can do this reasonably by having separate variables tracking "task complete" and "story complete".  For each task, have a "task complete" transition that sets the "task complete iteration" to "current iteration" when the task is done.  Now if you want to add up how many task hours got done by iteration, you don't need to worry about when the story is marked complete--just sum your "task estimate" by "task complete iteration" and you're golden.

  • Avatar
    Tim Vold

    Here's a couple pics: first is cumulative Release Burn up; second is same chart but cumulative is false, so it shows velocity by Sprint (eg. Iteration).


    Sprints == Iterations.


    Regards,


    Tim

  • Avatar
    Chris Leon

    Right, I'm not really tracking 'story points', just estimated task hours total vs estimated task hours complete vs actual hours complete.  Between the first two, it lets me know whether we need to be tasking out more work because we're in danger of running out, and the second and third let me know what correction factor I should apply to our estimates to scope out two weeks worth of work.


    I've attached a copy of the chart I'm using, along with the MQL it's based on.  Note that the where clause right now is based on what Iteration this task is currently a child of (via Card Tree).  I'm not so much concerned about booking credit via story points as just seeing rate of change in estimates, accomplishments, etc, over iterations.  I'm imagining the case where I have two charts, one for the previous iteration, one for the current one.  Some tasks for a story were done on the first one, some on the second.


    I could take your approach, and leave the 'current iteration' chart pretty much as is, based on what tasks are within this iteration AND not finished during a previous iteration.  The 'previous iteration' chart could have a where clause based on tasks finished within that iteration, and do the totals as is.  The only thing that wouldn't cover would be the black line, which is sum of estimated work scoped for this iteration at some point.  I'm starting to think a desire for that is overzealous reporting on my part though, cause all that I really care about on past iterations is how much estimated work we got done in a fixed period, and how much that differed from actual time spent.


    Thanks, that definitely helps me figure out what I want here.


    MQL


    <pre>


    {{
     data-series-chart
        conditions: Type='Task' AND 'Iteration' = (Current Iteration)
        cumulative: true
        chart-height: 350
        x-title: Date
        y-title: Work
        x-labels-start: 12 Apr 2009
        x-labels-end: 24 Apr 2009
        x-labels-step:
        series:
        - label: Scheduled
          color: black
          type: line
          data: SELECT 'Reporting - Added to Iteration', SUM('Work - Estimate')
          trend: true
          trend-line-width: 2
        - label: Complete
          color: green
          type: line
          data: SELECT 'Reporting - Closed', SUM('Work - Estimate')
          trend: true
          trend-line-width: 2
        - label: Actual
          color: blue
          type: line
          data: SELECT 'Reporting - Closed', SUM('Work - Actual')
          trend: true
          trend-line-width: 2
    }}


    </pre>

  • Avatar
    Tim Vold

    Couldn't figure out how to upload multiple pics as once.  So here's the second pic.

  • Avatar
    Suzie Prince

    Hi guys


    Wondering if this post about reporting on incomplete work may help? I haven't had a chance to completely look at whether what you're trying to report on is the same but, on the face of it, it is a similar problem.


    Thanks


    - Suzie

Please sign in to leave a comment.