Dear reader, I came across with this article to tell you about an experience that I’ve been living since a few months now — the experience of moving from a waterfall to an environment. I’m not an Agile nor a Scrum guru, but I’ll be giving you what I have been learning both from my experience and what I’ve been retrieving from some books and articles. This is part 2 of 3. agile In this article I’ll be giving you a brief overview over and scrum and then, in part , I’ll be addressing some minor topics that are important to make all this work. agile framework III Agile Agile is a methodology that describes a set of values and principles for software , that aim to guide software development teams to seek for the evolution of requirements and solutions along with an adaptive planning, fast deliveries, short development periods and continuous improvement. development It embraces change instead of fearing it. However, it doesn’t give you any receipt to accomplish any of its values and principles, that’s responsibility and in this article I’ll be giving you a brief overview over . agile frameworks’ Scrum The agile manifesto The is the key behind any agile environment and describes a set of and that you must address. But if you work in a waterfall model like I used to, you’ll need to change most of your day-to-day work in order to achieve these. agile manifesto values principles That’s where frameworks like Scrum come into play, defining roles, artifacts and cerimonies. Scrum framework I would like to focus just on a brief overview around the framework but I believe there are some core concepts that you’ll need to read about to understand the bigger picture. Let’s commit ourselves to this little task: We cover the overview now but if at you don’t know what is a “Product owner”, “a Scrum Master”, a “daily meeting”, etc. You jump to the “Appendixes” at the end of this article to find more about it. any point Let’s do this! So, this image above represents all you need to implement Scrum. Putting all these in practice doesn’t necessarily means that you work in an agile environment but… baby steps ( ). quick read about this Like I’ve said , our goal is to split our project in several stages so we can deliver more often and get feedback sooner. This image represents each of these cycles and they are known as . before Sprints Sprints must last between and always with a s and with a . In the middle is where our product gets implemented and at the end of each sprint we must always have a new working version of our product, a (we’ll see right next why this fancy name). 1 to 4 weeks start print planning finish sprint review/retrospective ( Appendix C ) Potentially Shippable Product Let’s see all the stages of a from the paper to production! user story From the idea to production All ideas can be turned into , , , etc. And all these can become or simply . All the scrum team members can have a word about each new idea but the Product Owner (Appendix A) is the one responsible for deciding if it turns in a PBL item or if it’s discarded. user stories spikes tech stories product backlog items ( ) Appendix B trash When the PO has enough PBL items (5, 8, 10…) without any measure, he gets the Scrum team together, explains each one of these so everyone gets the same understanding, and then each member of the Dev team (Appendix A) gives his estimation using — this is called (Appendix C). story points Grooming So now our new idea is a product backlog item and has its estimation, it’s time to define its priority. At the product backlog, items are ordered from high to low priority from the top to the bottom and the PO is the one responsible for managing this order. When our initial PBL item gets at the top it’s time to get it into the next Sprint! Like I’ve said, every Sprint starts with the Sprint planning. At Sprint planning the scrum team gets together and decide which items go into the (Appendix B). But how much items can we place at the Sprint backlog? That’s something I’ll address in part but for now I can say that it’s related to and . Sprint backlog III story points team velocity Once our (Appendix B) is defined the Dev team can start implementing each one of the items and see its progress at the . The is composed by the several stages, for example: And an item must be marked as done only when: Sprint target Scrum board Scrum board WIP, Code review, UX Review and Done. Meets all its acceptance criteria Accomplishes the Definition of done Passes through the different stages in the Scrum board During the sprint, the Dev team and the Scrum master make (Appendix C) where each team member answers essentially to this three questions: daily meetings What did you do yesterday? What will you do today? Are there any impediments in your way? The goal here is not to punish someone by his performance, but to understand the sprint progress and check if someone is stuck with something. This way we can all be aware of the state of our initial idea and how much is it close from getting done. Then, at the last day of sprint we have our sprint review and retrospective (Appendix C). These two can occur in any order. The Sprint review is also known as the demo meeting, because is a meeting where the Scrum team must demonstrate the new version of the product to the stakeholders. This is our . A new of our work that Potentially Shippable Product working version can be shipped to production! . (Our idea is finally this close of seeing the day light! yay!!) The Product Owner is the one responsible for deciding whether this new version goes live or not “Oh nooooo. How can I ship something I’ve just implemented???” Remember that and and all that? it all must be part of it. It’s the only way you can achieve continuous delivery effectively. DoD acceptance criteria Quality assurance, unit tests, integration tests, end-to-end… And now the question… “Ok. I have all my stories implemented and tested but I have the “users module” that only has the list of users. It doesn’t make sense to put it into production yet.” Well… In this case I can tell you about two approaches. The , as simple as that. It is a potential ship so… If the PO doesn’t find that new version valuable enough to be deployed so don’t. Potentially Shippable product isn’t shipped . Remember ? They do exactly that. You don’t compromise your delivery by unfinished developments. Simply use a parameterization system and enable/disable features. This can also be useful for for instance. Use feature toggles those videos from spotify that I shared with you previously A/B testing And finally, when the PO founds a new version of the product valuable enough to be available to our users, our idea comes a feature in production! I’ve just gave you a quick walkthrough about Scrum but guess what? There’s much more to learn about it. In part I’ll be covering some additional topics. III If you have any question, please reach me in the comments. I‘ll try my best to help you. Appendixes Appendix A — Roles Scrum master The Scrum master is the one responsible for establishing a balance in the Dev team giving them some alignment along with some autonomy. His responsibility is to resolve any blocking issues, to introduce any new techniques that may help the team to develop better and faster, to defend the team vision and to build trust not only in the team but also with the stakeholders. His main goal is . increase the team velocity as hard as he can Product owner The product owner is who holds the product vision and direction. He is the bridge between the Scrum team and the customers and other stakeholders. His main goal is to the deliver the product that better suits the client needs and for that he has to continuously collect feedback from them and evaluate which changes must be applied to improve the product. PO holds the product value and SM holds the dev team vision. Development team Dev team are the doers, who make it happen! Their responsibility is to execute the PO vision with the help of the Scrum Master. The team is comprised of the people needed to deliver the work — developers, testers, architects, designers… anyone who is needed. And its size must be ideally around 7, plus or minus 2 people. Scrum says that in a dev team titles and roles must be removed so we can achieve cross-functionality . Where the mindset is . “I’m a team member who is responsible for delivering this work and I cannot do it alone” Appendix B— Artifacts Product backlog The product backlog is a list of items prioritized by business value and risk, describing features and functionality needed to implement the vision. Anyone can contribute with new items to this list, but it is product owner’s responsibility to maintain it, keeping it up to date, prioritized or ordered, and clear. This is a living document that never ends and items can be added and removed at any time. There are several types of product backlog items like user stories, epics, ideas, spikes… The important thing is that, those who are at the top (biggest priority) are clear and well detailed and those who are at the bottom can be more vague since are not the focus for now. Sprint backlog The sprint backlog is simply a subset of product backlog items with the highest priority. When a new sprint beggins, some of the items are moved from the top of the product backlog and putted into the sprint backlog. This builds the sprint target. During the sprint, items move from the sprint backlog to different stages in the and an item is identified as done only when it meets all its and the . Scrum board acceptance criteria Definition of Done “When a backlog item is described as ‘Done’, everyone must understand what ‘Done’ means.” Appendix C — Cerimonies / Mettings Grooming The gromming happens when the PO has enough new Product Backlog items that need discussion with the team (i.e. at any time during the sprint). In this meeting PO explains each one of the items so everyone can understand it in the same way and then each element from the Dev team gives his estimation using . story points From this meeting, new items can be added, other may be removed, some may be changed and the list’s order may change too. Sprint planing The sprint planning can be split in two parts. The first is where the PO says he want to be done during the sprint (the sprint target/goal), the second is where the team defines it will be done. The PO doesn’t have to be present in this second part since he doesn’t participate in technical discussions. what how Daily meetings The daily meeting is the opportunity for the team to sync. This meeting is led by the SM and every team member answers the following standard questions: What have you accomplished since the last meeting? What will you accomplish today? What impediments or obstacles are in your way. Sprint review On the last day of the sprint the team holds the sprint review. It is also known as the “Demo meeting”, where customers have the opportunity to review the progress made on the project to date. This is where the team can collect valuable feedback from the customer. In this meeting the team must ask for acceptance from the customer. Sometimes customers say that some functionality was not delivered or was not delivered as expected. In those cases, work might be putted back on the product backlog. Restrospective The sprint retrospective also happens on the last day of sprint. It provides the team an opportunity to identify ways in which it can . It is important to the SM and every element of the dev team to be present, the PO is not required to this meeting. improve its work process and execution (These improvements are known as .) Kaizen
