One important part is once you have broken the project up into tasks, is to simplify (eg: these two tasks could be different views of a core feature) once you h

One important part is once you have broken the project up into tasks, is to simplify (eg: these two tasks could be different views of a core feature) once you have all of the tasks in hand. If you try simplifying before you have a mostly complete idea of the scope, you end up with useless abstractions and other overly complicated code (eg: the ObjectServiceFactoryConfiguratorEngine that only loads a simple json config file during app startup that took months to write). Also, I've found it handy to have a line or two of the issue this is trying to solve for the user in the user story. To go with the user story example in the article, it should also have: "User frequently schedules appointments from the animals they have viewed recently". That way when implementing the feature one can tell if they are over complicating things when the user actually wants something to make their job easier/simpler or can help uncover hidden requirements that were undiscovered in previous steps (eg: the buttons should be blindingly obvious or more hidden).