We are a small IT team in a startup and are composed as such:
- 2 frontend engineers (1 senior, 1 junior)
- 2 backend engineers (1 senior, 1 junior)
We recently (3 months ago) started to use a Scrum methodology to manage our projects. It brought us stability and better communication (thanks mainly to the daily stand up meetings). So overall, it's a good change.
But, one thing remains. We try to estimate our stories by complexity, and assign a certain number of points for each sprint. Our team being small and the experiences in the different aspects of our projects, we have to assign specific stories to specific people in the team.
How can we know if we estimate by complexity, at any given moment, if we're ahead or behind schedule? Our sprints are two weeks long, we can't afford not knowing if we're late until the end of the sprint. Knowing that we missed our deadline at the deadline is pretty useless... And we can't rely on the estimation being diluted across the team, as we are this small.
Another thing I don't really get is we select the stories, let's say 120 points, for 2 weeks. It's a mean of ~30 / person so my engineer's brain is telling me that I should, give or take, do 3 points per day. If on the third day I'm at 9, I'm good. If I'm at 6, I'm behind. But there I'm back on a time based estimation...
I guess I don't get the thing about complexity estimation. I understand the power behind relative estimation, as this answer explains it, but I don't see how I can keep track of the well being of the project while in a sprint.
Nota bene: we do have a burndown chart, which is not that useful for my conceptual problem as it draws a chart of complexity over time. Therefore, can I deduce that the points are time-based in the end ?