There is a significant shift that has happened in companies from waterfall methodology to agile methodology. Story cards are developed and bundled in milestones. Milestones are great in measuring the progress and determining the scope of the project. Milestones need not to be always set in a fixed time manner like monthly or quarterly. Often gaps are created in milestones to do other projects. A rhythm that can be set up for every Monday is a good option because it will help in getting small incremental changes that will help implementation team. But some point of time weekly cycle appears to be very fast. It is very necessary to determine that what is really feasible to achieve for the team. Read the full article here: http://it.toolbox.com/blogs/original-thinking/how-fast-does-your-agile-sprint-71351

Two main goals of Agile Sprint are building new functionality and building new knowledge. Building new functionality seems obvious for sprints, but teams also need to focus on building knowledge.  Each sprint should end smartly from its inception.  A UI designer should focus on both of these goals. Within a sprint, a UI designer helps in coding and testing of his/her design while simultaneously, he/she focuses on the next design feature to be built. A UI designer's top priority should be working in the current sprint. If a developer or tester needs any clarification regarding the design than he/ she should immediately halt the work and attend to their queries. But then one might say that every member of the team does so. Be its analysts, architects, database designers. The difference lies in the amount. Designers spend majority of time in building knowledge. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/incorporating-ui-design-in-scrum-sprints

Agile teams must embrace change. After all, that is what agile means, right? Accommodating changing customer's requirement… But the stakeholders or customers must also understand that nothing comes for free in the world. So are changes. They have a cost related to them. Scrum works on a rule that once the required changes are fully stated, a sprint begins. And no changes are allowed into a sprint. Once a sprint is started, it’s not disturbed and the team’s entire focus is on selected work. This is good and works efficiently, but can sometimes backfire. The customer can question that the foundation of being agile is to welcome changing requirements. Well, yes, but they aren’t free. Customers must understand that changes introduced beyond a certain point have a cost related to them. And both the customers and organization should work together to optimize results with the minimum cost.To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/change-isnt-free