4 ms·
Sounds like every agile team I've ever worked on - sprint and iteration is usually interchangeable. The problem is that Devs making estimates tends not to be a
by mattlondon 7y ago
Sounds like every agile team I've ever worked on - sprint and iteration is usually interchangeable.
The problem is that Devs making estimates tends not to be accurate IME. Some stuff is easy to estimate, but adding in new & significant functionality is notoriously usually hideously mis-estimated (either high or low). So much so that the numbers basically b come meaningless and can't be relied upon because every major new thing was a lot easier/a lot harder than expected.
The reaction to this is to split the task up, but this often requires that you do a lot of pre-work-work to architect and design the work so you know how it can be broken up, and that design work needs to be estimated so you are back at square one with wildly inaccurate estimates.
- latchkey 7y agoIf the story estimation isn't accurate, then the velocity goes haywire and this shows up in the reporting in Pivotal Tracker. So like you said, devs learn to get better at forcing the PM's to split the stories into smaller chunks. Smaller stories are almost always easier to accurately point since it is always 2 (1 point for the story, 1 point for testing). The numbers are not meaningless though. That is why velocity is an average of 3 weeks. A single week doesn't blow things out of the water and if it is a new project, the expectation is that we won't know where we are at all those first 3 weeks. It gives a built in ramp-up period for the project. Agreed, the PM's role is SUPER important. For this reason, at Pivotal the PM's usually have a developer background.
- ec109685 7y agoAren’t you putting all your faith in the PM in this methodology? The way you describe it, a developer’s role is to point out stories and jointly perform the work the PM has allocated. Instead, if those same developers understood the users, use cases and metrics and co-created the work the team does, the team would have 10 or mor engaged minds all working to make a better experience instead of the one super PM.
- latchkey 7y agoIt isn't black and white like that. The team always has a voice and can express it at any time. Communication is always key and that is the whole point of developers pointing stories. They could just call a story 8 points and the PM would never get it into the backlog. =)
- ec109685 7y agoRight, but that is different than the PM asking the development team what we should do this iteration.
- latchkey 7y agoThe PM is the conduit between the business needs and the developers. The PM and the lead team dev decides the backlog. Devs just pick the next story from the queue, but of course they have input on things as well and can convey this in any of the meetings or directly with the core dev or PM.
- ec109685 7y agoYes they can coney things, but it isn’t by default. Having conduits, etc. is a waterfall approach.
- faeyanpiraat 7y agoThere are lots of devs who have a personality that benefit from having a leader (PM). Also when you are doing the 101st CRUD type function in an app, you probably cannot be that enthusiastic about managing yourself either.
- whatshisface 7y agoHow can this state of affairs where developers grind out CRUD features and complain about how bored they are be stable? The identifying feature of areas where automation would be profitable is human boredom, and this is something where developers are the ones bored. Why hasn't all of the repetition in CRUD stuff been dealt with by now?