World Of Agile

Scrum relies heavily on the concept of Timebox. Timebox is setting a fixed time limit to any activity and letting other characteristics such as Scope vary. A time box could be ·           A Meeting ·           A Sprint ·           A Test activity ·           Development Activity ·           Or Practically anything such as you chatting with your friend on social networking site. The fact about timebox is that the time is limited. You can adjust other parameters such as ·           How much you can get done ·           Which item you must prioritize ·           However, deadlines cannot be moved. In Scrum, all the project iterations, meetings must be timeboxed and time limits be respected. This is very important and non-negotiable aspect of Scrum. Lets look at how a timebox actually works. ·           Timebox can be of any duration  - hours, months, years ·           It is essentially a control mechanism to ensure how much time you wish to devote

Implementing Continuous Integrations The practice of Continuous Integrations (CI) relies on certain pre-requisites being in place. ·         Version Control Everything in your project must be checked in to a single version control Repository ·         An Automated Build You must be able to start your build from the command line. You can start off with a command-line program that tells you IDE to build your software and then runs your tests, or it can be complex collection of multistage build scripts that call one another. ·         Agreement of the Team If people don’t adopt the discipline necessary for it to work, your attempts at continuous integration will not lead to the improvement in quality that you hoped for. Automated testing is one very useful side effect of implementing CI. With CI, we can detect Integration issues much earlier in the process All the stakeholders including the business partners can see the small Changes deployed

The Primary Team roles in scrum are named as • Product Owner  • Scrum Master • Development Team Scrum Master, Product Owner, and Team are considered as people who are committed to the project while customers and executive management are considered as involved but not committed to the project. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.  Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available. All the roles are based on the concept of “Servant Le

Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of done is critical because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms. This clear definition is used to create the Done Criteria when a Prioritized Product Backlog is prepared. Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well. DoD is a checklist of valuable activities required to produce software. Definition of done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added steps allows