Some comments: * Design and architecture tasks are stories, just like development tasks are. Definitely put in stories to develop a product architecture up-fro

Some comments: * Design and architecture tasks are stories, just like development tasks are. Definitely put in stories to develop a product architecture up-front, and do them in the first sprints. Don't just start building stuff without a plan. * One story per week doesn't sound like enough. Either your stories are too big, or you need longer sprints. A common rule is that no story should take more than two days to complete; if it's bigger than that, then it gets broken down into two or more smaller stories. * The main benefit of Agile/Scrum in my mind is that it provides a built-in measure of progress, as well as feedback on the quality of your estimates. There's no need to have team members monitor each other (other than pair programming and code review) -- for each sprint, you should plan how much you are going to do, execute it during the sprint, and then review whether you got done what you said you would. If not, then you need to revisit either your estimation (points per story) or your velocity (points per sprint). If you don't do this, then you're not really doing Agile. Ultimately, if you do this rigorously (architect the product up-front, capture your stories at the start of the program after you have the architecture, spend time sizing your stories, and rigorously track completed work at each sprint review), you will get a MORE ACCURATE prediction of when you will finish the project than you would if you had planned via waterfall. If you have a fixed ship date, you can then take the choice to triage stories, based on the amount of work you know that you can get done.