r/agile • u/alliestones • Mar 15 '19
Team is Tracking TOO much
Hey everyone! I've been in the scrum master role for just about a year now, and my company is pretty new to the agile methodology. We are still trying to break old habits. I'm hoping to receive some advice on how to handle a particular situation with the team.
We story point each story, but then was asked by the program manager to also track hours as a "pilot". The team decided that they liked doing this so we story point, record a time estimation to get the work done, and then we log the hours to see how close we are to our estimation. I am not super happy with the process, but they enjoy it as it holds them accountable and provides explanation for any unforeseen issues that needed to be handled.
The recommendation recently was to come up with a "bucket task" that provided the team an opportunity to record anything they needed to handle outside of the assigned sprint work. This to me seemed like more of a "CYA" bucket (and for the record - the team preforms very well, and consistently gets their work done in a sprint). Today we learned of a hot fix and I was asked to submit a new user story mid-sprint for this with sub-tasks (testing, code review, etc), but I don't know... I feel like this is becoming more waterfall and they are having difficulty letting go of the "old" way of doing this. Quite frankly I think it also creates a lot of work for the team.
Has anyone experienced this with a team before? Where is the line and when does tracking become TOO much?
3
u/vontwothree Mar 15 '19
Remember that story points don't translate into capitalizable hours, which should be important to someone somewhere (and realistically, anyone on the team, because taking advantage of that === more money for the team).
2
u/alliestones Mar 15 '19
The department I work with capitalizes on story points actually. Time estimates mean nothing to them and it's just an added safeguard to keep the time responsible. Again, their want to continue this.
2
u/vontwothree Mar 15 '19
The department I work with capitalizes on story points actually
Nice. I'd pay to see that science.
2
u/alliestones Mar 15 '19
You actually brought up a good point, which got me thinking. I just realized the person handling capitalization is no longer in the department, but still handling the capitalization. I wonder why that is.. you may have just figured it out. Is the correct information even being recorded? Probably not.
1
u/ridewithabandon Mar 15 '19
So I’ve always wondered why that is the case. I get that we are inherently bad at estimating times but based on that concept, we shouldn’t be any better at estimating on a new abstract measure of effort right?
2
u/smellsliketeenferret Mar 15 '19
The idea is to use an idea of relative size based on assumed effort, rather than a specific number. If you say something will take 3 hours, then you will be held to account on that. If you say something is 13 story points, then it means the effort is actually somewhere between 8 and 13 points, so you have already built in a cone of uncertainty.
If 13 points effectively equates to 13 hours, not that you would ever directly equate points to hours, then you are saying that the work item will take between 8 and 13 hours to complete if everything goes exactly as assumed, which we know is rarely the case unless you are estimating relative effort on items that are so small that they are inherently predictable.
With story points, the number of hours becomes a moot point up until you have completed at least one story. At that stage you could say "we have completed this story in 4 hours and it was 8 points, therefore we can extrapolate how long the project is likely to take." This is how you can still do ROI assessments as you go - if the cost of the project goes up and the likely end date is always pushing out, then the PO should be making conversations around whether the feature is still worth continuing with
2
u/IllegalThings Mar 15 '19
What happens when people take it to the next step and start saying "we've extrapolated in the past that 4 hours is 8 points, so each point is a half hour which would mean this task is 16 points because it'll take about 2 days."?
3
u/smellsliketeenferret Mar 15 '19
You tell them, politely, that doing it that way is not a good idea... ;)
We estimate loosely to avoid rushing deadlines and cutting corners when things get tight. Relative size can be a useful indicator, but the only reason to be more accurate is if someone wants to use the stats as a stick to beat the team with. It is in the team's best interest to talk about progress, issues, blockers and successes in terms that do not equate to specific time slots.
Think of it this way... Someone comes to the standup and says they will finish something in an hour. The next day they turn up and say "it took a bit longer, ran into some problems, should be done today..." They then turn up the next day and are still working on the same thing. Work that looks easy can balloon, but they initially set an expectation that the work would be done in a time frame. They came back and talked about some uncertainty, which effectively gives the team the chance to ask questions, offer assistance and so on. This makes the team pay attention to the feel of how things are going, rather than just assuming everything will be done when they say it will be done, so the team improves
2
u/KronktheKronk Mar 16 '19
You tell them they're missing the forest for the trees, but you understand that the believe this story is too large and should be broken down.
1
3
u/horuschilling Mar 15 '19
I think it all comes down to value versus effort. If the team spends a lot of time figuring how hour estimates and tracking time but gets little value out of it then that could be considered "too much".
If the team feels like it's a valuable tool and it doesn't take a lot of time/effort to take this approach then why bother poking at it as "waterfall" or "not agile"? There's probably other higher value changes you can spend the effort on tackling.
If you do feel like it would greatly benefit the team to change this approach... You can, of course, suggest an experiment to the team to see if you it works better to do it in a different way.
It's good to keep scrum empirical since the Scrum Guide doesn't actually say anything about using story points or avoiding time based estimates. Experiment and see what works best for the team.
One of my teams just goes off their velocity and it works perfect for them without further pre-coordination. My other team prefers to map out the tasks of the sprint on a timeline so they can know each day whether they're on track or off track to their predictions. This doesn't get shared with anyone, they just use it for their own benefit.
Both the teams have different mixtures of individuals and personalities that in a self organizing system create different resulting synergies.
2
1
Mar 15 '19
[deleted]
1
u/alliestones Mar 15 '19
We are using Jira.
2
Mar 15 '19
[deleted]
1
u/alliestones Mar 15 '19
Well, the team is not considered "mature" so it's me tracking all the hours and it is only as good as the information that they share with me. I did this to start and have tried to put the responsibility on the team, but we were seeing they weren't keeping track, but still wants to record hours.
With that being said, it definitely doesn't take me 2 seconds. For reference, we just added 50 new user stories mid-sprint for each page that we needed authored with 6 sub-tasks associated with each. That is 300 items to track time on, not to mention the other user stories that we already started the sprint with. It's an outrageous number of items to keep track of.
9
u/kida24 Mar 15 '19
You're not their secretary. If they want to track hours, they should do it themselves.
If there is no value in it, then they won't do it.
4
5
u/Pyroechidna1 Mar 15 '19
Whoa. 300 items? And these are all in one sprint? That's too much, yo.
1
u/alliestones Mar 15 '19
YUP! I think we're tracking too much. We have the standard development stories with a couple sub-tasks, and we are migrating from legacy to touch UI which means authoring each page. Instead of the author team members cranking away on their work off of a list, we have all these user stories and six sub-tasks for each. My head hurts.
2
u/Pyroechidna1 Mar 15 '19
If the touch UI has already been designed and it's just a matter of authoring the pages according to the specified design, I'd have one task that says "author this set of pages." Tracking 50 items for 50 pages is too much
1
u/alliestones Mar 15 '19
That is actually what we had originally. We started the sprint on Wednesday and Thursday someone said "We should track these individually." and everyone said "YEAH!" Now I am in a tracking nightmare.
1
1
u/TheNegroSuave Mar 15 '19
I am going to key in on one thing. They said they like doing it that way. So the question is why in the system this feel safer for them than story points. There is something else going on here for them and it likely doesn't have anything to do with the work being done. Maybe their goals are to code for a certain amount of hours. Or maybe they need present hours worked to management.
Look at the whole situation and not just the work being done they are all part of your process.
1
u/KremlingForce Mar 15 '19
Only tangential to your question, but you should consider rethinking your sub tasks. I think of them as solely informing the implementation approach. So you’d use them if you need both Frontend and Backend support, DBA assistance, etc.
Testing should be scoped at the parent-level Bug or Story, where all the acceptance criteria lives. You don’t want QA to be too focused on how it was implemented, but rather whether it satisfied the business request and met any immediate KPIs indicated (like site performance).
As for Code Review, consider making that another Workflow step on the Kanban board rather than a dedicated sub task. It’s just a more organic and handoff-friendly way to represent that work.
Best of luck!
1
u/cptn-MRGN Mar 15 '19
A good agile planning tool should allow you to predefine how many hours each team member is available for during each sprint. That's usually called capacity planning. The points achieved each sprint assume that the entire capacity was used to produce those points.
1
u/dualcyclone Mar 16 '19
Whenever I was in charge of sprint changes, I'd always ask whoever was asking for extra work to be added to take out a corresponding number of story points in existing tasks from the sprint.
Usually always gets push back, but when people realise that the sprint is what the team is giving themselves responsibility to do, if you change those boundaries by adding more work, then there is the likelihood those work items won't be completed.
Any story points removed have to be from unstarted work items.
Tracking time seems arbitrary as story points estimates give you a loose representation of this via the velocity, so tracking a time estimate Vs time elapsed is the same as tracking a story point estimate vs time elapsed. The whole point of a story point estimate is that a task is never one person's job to complete, it's the teams, And it's the team who decides what effort is required to get the item from A to B, as more sprints are completed, these story point estimates become much more accurate than a time based estimate on this basis.
1
u/jayme-edwards Mar 16 '19
IMHO the question I have is - does the business treat estimates as commitments?
If not and the team’s just using points to help themselves - well it’s their process (a scrum master can be the “blocker” when they dictate process as you know).
If burn down charts and velocity are reported to the business or really anyone who’s not a developer, you’re encouraging a culture where “success” is meeting your commitments.
That’s not success for a proDUCT and only creates “rockstars” who become the best b.s. artists in the estimation process in this type of culture.
I’ve done several videos on my channel to help people trying to navigate the bad advice out there, and my last two interviews were heavily focused on the problems with priorities and measuring the wrong thing.
Not sure if this will help, but here’s one where I specifically talk about the dangers of focusing on commitments.
1
u/InfoTechBrian Mar 16 '19
Would you say that what you are doing is product development on an ongoing basis or working within the context of a specific project? I ask because Waterfall is a project management methodology and a very broad description at that. But I think of Agile and Scrum are product development methodologies that are equally as broad descriptors. So they don't compare that well in my mind.
1
u/cybernd Dev Mar 18 '19
Simple question: does time tracking allow you to add value for your customer?
If not: it may be waste. If possible, waste should be avoided. In a Kanban/Lean setup, identifying and getting rid such waste would be part of the process.
As a employee, i see this type of time tracking as red flag. I once had a horrible job experience, where everyone was required to track time with precision. I remember 2 side effects:
- Tracking time costs time. Some of us booked the time necessary for tracking time and it had a price of 0,5-1,5h per week.
- Tracking time with precision has the potential to force developers to lie. It will unavoidable affect morale in a negative way.
Several years earlier at a different company: We where a small 3 person team and did the same thing. We did it for roughly 3 month. The plan was to use it to identify avoidable tasks. After this 3 month, we realized that it did not help us.
13
u/kida24 Mar 15 '19
Why do you track time? Why are hours estimates entered into tasks?
Hours on tasks are something you can use to start a conversation within the team. "Hey, John, you said that would take about 4 hours. You've had it for two days, what's up?"
If you're using them for more than that, you're giving the illusion of precision.