In my last team we estimated story points, tasks, and task hours. (The latter two were frequently inaccurate.) We entered worked hours daily. Every day reminded me of the time pressure. The pro is: I stayed more focused and got more stories done. I didn't get too distracted with "gold plating" my features, or if I did it was on my own time. But the time pressure also meant more shortcuts (technical debt) and reduced business impact. By reduced business impact, I mean sometimes the work technically fulfills the story but doesn't quite please the stakeholder. Which may result in another story.
In my current team, we started out doing estimation similarly. We eventually stopped tracking/estimating hours, then stopped estimating tasks. Devs can use tasks however they like on their stories. I still try to estimate stories with t-shirt sizes -- small, medium, large. We only put 1 large story per person in a sprint. We also do design sessions for many/most stories. The pros and cons are pretty much inverted from the previous team. We work with stakeholders to make sure stories match their expectations. We fix bugs right away. We address important systemic issues. But we can't be sure when a specific story will be done. Large stories can end up spanning multiple sprints. I mainly report stories in progress to my boss. Sometimes milestone progress and next stories in queue. But I get pretty uncomfortable when asked for estimates or timeframes, and just give my best guess.
Having said all that, these two situations are apples-to-oranges. My last team was working on an old internal system. The broad strokes of functionality were well established long ago. Many of the backlog stories were increments and refinements. The estimates were still inaccurate and irritating. (Because time pressure also discouraged doing enough design for closer estimates.) We got into a regular cycle of alternating between over- and under-estimating. But this "feature factory" approach worked well enough. I had a great team and manager, so I was content overall.
In the current team, we are building a collaborative product while learning new tech and patterns. (It's actually worse than that -- a cloud redesign of an existing product. The MVP scope was giant.) New features can affect multiple personas/apps and have major interactions with previous features. Sometimes a feature isn't useful in smaller pieces. It is developed end-to-end by one person. Front, back, database, everything. So yeah it can span more than one sprint. When we did task/hour estimates and burndown, they just created busy work with continually changing them to match reality. Especially at the start when so much is being discovered. Note that we have released 2 products under this scheme.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have some experience in both.
In my last team we estimated story points, tasks, and task hours. (The latter two were frequently inaccurate.) We entered worked hours daily. Every day reminded me of the time pressure. The pro is: I stayed more focused and got more stories done. I didn't get too distracted with "gold plating" my features, or if I did it was on my own time. But the time pressure also meant more shortcuts (technical debt) and reduced business impact. By reduced business impact, I mean sometimes the work technically fulfills the story but doesn't quite please the stakeholder. Which may result in another story.
In my current team, we started out doing estimation similarly. We eventually stopped tracking/estimating hours, then stopped estimating tasks. Devs can use tasks however they like on their stories. I still try to estimate stories with t-shirt sizes -- small, medium, large. We only put 1 large story per person in a sprint. We also do design sessions for many/most stories. The pros and cons are pretty much inverted from the previous team. We work with stakeholders to make sure stories match their expectations. We fix bugs right away. We address important systemic issues. But we can't be sure when a specific story will be done. Large stories can end up spanning multiple sprints. I mainly report stories in progress to my boss. Sometimes milestone progress and next stories in queue. But I get pretty uncomfortable when asked for estimates or timeframes, and just give my best guess.
Having said all that, these two situations are apples-to-oranges. My last team was working on an old internal system. The broad strokes of functionality were well established long ago. Many of the backlog stories were increments and refinements. The estimates were still inaccurate and irritating. (Because time pressure also discouraged doing enough design for closer estimates.) We got into a regular cycle of alternating between over- and under-estimating. But this "feature factory" approach worked well enough. I had a great team and manager, so I was content overall.
In the current team, we are building a collaborative product while learning new tech and patterns. (It's actually worse than that -- a cloud redesign of an existing product. The MVP scope was giant.) New features can affect multiple personas/apps and have major interactions with previous features. Sometimes a feature isn't useful in smaller pieces. It is developed end-to-end by one person. Front, back, database, everything. So yeah it can span more than one sprint. When we did task/hour estimates and burndown, they just created busy work with continually changing them to match reality. Especially at the start when so much is being discovered. Note that we have released 2 products under this scheme.