Hi Venu,
Here comes a raw stream from my Agile coach :
Two week sprint equals 10 working days equals a max of 60 working hours per person. The granularity of your stories should be around 5 stories per person per sprint (give or take a bit).
If stories are habitually not being finished, then there may be an issue with story definition and/or story sizing. Planning to exactly 100% commitment is setting yourself up for failure.
The overriding mantra here is: plan to complete by committing to less, but pull items forward if you finish early. This removes the problem with tasks taking more time than you planned. It still allows you to delight your stakeholders because you occasionally bring things early.
Something going red is not necessarily a problem. The same goes for story points: if you finish early and pull stories forward, your sprint metrics go red because you end up with more stories and points in the sprint than you originally forecast. So what do you in this situation? Manually update the sprint capacity every time you pull a story forward?
Accept 'red' as something to note rather than something to fix.
You might find this custom app useful in your management of the team:
https://github.com/nikantonelli/TeamLoading------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------
Original Message:
Sent: 10-30-2019 03:32 AM
From: Venu Jetti
Subject: Team Status page
Hello Eric,
The Situation:
If a story is not DONE by the end of the sprint, the story will be carried forward as it is. We do not want to just split the user stories for the sake of marking the stories DONE.
We also do not mark the tasks to individual team members during the planning to bring collective ownership of the sprint commitment instead of task ownership.
The problem:
Due to stories moving as it is, we get all the tasks of those stories moved with Estimates, Actuals. This is causing the individual team members capacity is shown in 'red' and overshoot.
What am I trying to solve with this?
I want to inculcate the habit of owning the tasks, filling the necessary details (Actuals and To Do) every day so that team can see the data during the retrospective about what tasks are taking more time and why are they taking. (reasons could be many; for example, learning involved, some tools can perform well, clarity on discovered use cases arrive faster, etc..)
The current Team Status page does not allow to generate to serve this purpose.
Thank you,
Venu
Original Message------
@Venu Jetti what exactly do you want to do from Team Status that you can't do with the current page? If you're looking to let users set their iteration capacity then Nik is right, there are only a couple of ways to do that and none of them support viewing extra fields. If you're more interested in task loading and other facets of Team Status then there might be other options if you want to outline your use case here.
------------------------------
Eric Nash
Principal Agile Consultant
Enterprise Studio by HCL Technologies
------------------------------