Question on Why we're Always Late

• Why we always have Quality Engineers and Info Devs trying to catch up with development? Is this because development is moving too fast and QE/ID too slow? Or is this because development moves to slow holding back QE and ID work? We shouldn’t be asking this questions in the first place if we consider everybody as part of a single team (no dev, QE, and ID for separate) and we have a consolidated Definition of Done. DoD is what can tell us if a user story is really completed or half baked. DoD should be common and all team should aim to complete user stories under this definition.
• One step back, why we plan for more than we can achieve? Part of this is because we don’t plan thinking as a team, development plan first and then QE and ID add their estimates. Development estimates might fit whiting the timeboxed iteration but QE and ID would most likely fell of the mark. The other part of this is because we don’t know for certain team velocity.
• Why we don’t know team velocity? We measure progress in hours but we plan in user stories, our backlog contains user stories that when moved to iterations are tracked down using burn hours. What Scrum recommends is using burn down charts for user stories not for hours. Burning hours is not a good indicator of progress, on the contrary, it often mislead us when we try to evaluate iteration progress.
• Velocity could be better indicator if we can estimate the number of user stories that the team is able to produce in an iteration. However, story points or other metric should be considered to have a correlation metric for user stories’ size and complexity.
• Are carried over user stories that bad? Without question carrying over user stories break the Scrum principle of having a Potentially Shippable Product at the end of each Sprint. Moreover, from a production stand point, carried over user stories creates a technical debt that will drain team’s capacity in the future.