A compilation of the absolute basics for those who want to know about Agile Methodology with some insights on Scrum. The idea is to give enough to fuel the curiosity to learn more. It might not interest one of he / she is an Agile guru but may I ask for your review / comments / suggestions. I'd love to hear from you all...
This is a short introduction to the practice of Sprint Planning in Scrum. It would be useful for people new to Scrum or Agile. For more, comment or write to read my blog : http://agilediary.wordpress.com/
Let's discuss this on my blog: http://www.sarfata.org/back-to-basics/basic-agile-practices/
My goal today was to extract the most important (IMHO) practices of agile methodologies that can be applied individually or together to improve the performance and well-being of project teams. I split those practices into two: practices for the developers, practices for the entire team.
My selection of practices included:
* Pair programming
* Collective Code Ownership
* Refactoring
* Test Driven Development
* Continuous Integration
* Standup Meeting
* Kanban (the post-it board)
* Time-boxing - Sprint
* Backlog
* Retrospective
Slides distributed under the CC-BY-SA license. As always feedback is much appreciated!
My thoughts on Agile and how it helps in successful product delivery as guest speaker for Graduate level course : Innovations and Entrepreneurship in the Information Industry taught by Nancy Gilby
The "2017 Scrum by Picture" is something you can call Scrum Guide illustrated. It is based on the newest version of "Scrum Guide".
You will find the theory, scrum values, scrum team, scrum events including sprint, sprint planning, daily scrum, review and retrospective as well as scrum artifacts. All of those is explained in easy to follow, illustrated nicely presentation, which can assist you to catch the idea behind Scrum.
Feel free to share "2017 Scrum by Picture" with your Scrum friends.
A compilation of the absolute basics for those who want to know about Agile Methodology with some insights on Scrum. The idea is to give enough to fuel the curiosity to learn more. It might not interest one of he / she is an Agile guru but may I ask for your review / comments / suggestions. I'd love to hear from you all...
This is a short introduction to the practice of Sprint Planning in Scrum. It would be useful for people new to Scrum or Agile. For more, comment or write to read my blog : http://agilediary.wordpress.com/
Let's discuss this on my blog: http://www.sarfata.org/back-to-basics/basic-agile-practices/
My goal today was to extract the most important (IMHO) practices of agile methodologies that can be applied individually or together to improve the performance and well-being of project teams. I split those practices into two: practices for the developers, practices for the entire team.
My selection of practices included:
* Pair programming
* Collective Code Ownership
* Refactoring
* Test Driven Development
* Continuous Integration
* Standup Meeting
* Kanban (the post-it board)
* Time-boxing - Sprint
* Backlog
* Retrospective
Slides distributed under the CC-BY-SA license. As always feedback is much appreciated!
My thoughts on Agile and how it helps in successful product delivery as guest speaker for Graduate level course : Innovations and Entrepreneurship in the Information Industry taught by Nancy Gilby
The "2017 Scrum by Picture" is something you can call Scrum Guide illustrated. It is based on the newest version of "Scrum Guide".
You will find the theory, scrum values, scrum team, scrum events including sprint, sprint planning, daily scrum, review and retrospective as well as scrum artifacts. All of those is explained in easy to follow, illustrated nicely presentation, which can assist you to catch the idea behind Scrum.
Feel free to share "2017 Scrum by Picture" with your Scrum friends.
What is the purpose of Sprint planning meeting in Agile?Mario Lucero
What is the purpose of the Sprint planning meeting?
When you’re working within an agile management framework, you accomplish discrete tasks within the framework of a sprint. On the first day of each sprint the scrum team holds the sprint planning meeting.
In this presentation, we summarize the most important content of the Scrum Guide.
The material can be used to share knowledge and have a common understanding among Scrum Team Members.
It is also a great summary for those preparing for the Professional Scrum Master I (PSM I) test
Scrum 101 Learning Objectives:
1. Waterfall project methodology basics - what is waterfall and where did it come from?
2. Agile umbrella practices and frameworks - what is agile? what isn't agile? Where does Scrum fit in?
3. Scrum empirical theory - emperical vs. theoretical
4. Parts of the Scrum framework - roles, events / ceremonies, artifacts and rules
5. Features of cultures that use Scrum
Rich Mironov's keynote for one-day agile workshop. Intro to agile development and agile organizations, tools, impact on whole organization, product management and product planning. Co-sponsored by AccuRev, Coverity, Electric Cloud, Enthiosys, Rally and Agile Journal.
What is the purpose of Sprint planning meeting in Agile?Mario Lucero
What is the purpose of the Sprint planning meeting?
When you’re working within an agile management framework, you accomplish discrete tasks within the framework of a sprint. On the first day of each sprint the scrum team holds the sprint planning meeting.
In this presentation, we summarize the most important content of the Scrum Guide.
The material can be used to share knowledge and have a common understanding among Scrum Team Members.
It is also a great summary for those preparing for the Professional Scrum Master I (PSM I) test
Scrum 101 Learning Objectives:
1. Waterfall project methodology basics - what is waterfall and where did it come from?
2. Agile umbrella practices and frameworks - what is agile? what isn't agile? Where does Scrum fit in?
3. Scrum empirical theory - emperical vs. theoretical
4. Parts of the Scrum framework - roles, events / ceremonies, artifacts and rules
5. Features of cultures that use Scrum
Rich Mironov's keynote for one-day agile workshop. Intro to agile development and agile organizations, tools, impact on whole organization, product management and product planning. Co-sponsored by AccuRev, Coverity, Electric Cloud, Enthiosys, Rally and Agile Journal.
Антон Семенченко, опыт в IT более 10 лет, работает в компании ISSoft, специализируется в разработке и автоматизированном тестировании ПО плюс менеджмент\продажи. C++ Architect, Automation Practice Lead, PM, Group Manager
«Agile ValueTeam, учимся понимать Scrum». IT секция. Agile отделение. Для всех уровней подготовки.
«Как эффективно продавать Automation Service». IT секция. Продажи.
«Как эффективно организовать Автоматизацию, если у вас недостаточно времени, ресурсов и денег». Development секция. Отделение тестирования.
Benefits of Agile Software Development for Senior ManagementDavid Updike
This is a presentation to Senior and Executive Managers which is used to explain how Agile Software Development processes and practices benefit them, their organization and their customers.
Testing for agile teams . What's the difference between this and other testing ? What are the goals for such testing ?
Is agile testing needed at all ? Why ?
You will find some answers inside and mist likely will be directed to the right way.
This deck gives an overview on the following key areas.
1) Agile Development Principle
2) Scrum Framework
3) User Story Creation
4) Definition of Done
5) Agile – Retrospective
6) Development – Metrics
7) Agile vs Traditional Development Approach
Product Owner in Agile/Scrum is the single person responsible for maximizing the return on investment (ROI) of the development effort
Responsible for product vision
Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans
Final arbiter of requirements questions
Decides whether to release
Decides whether to continue the development
Considers stakeholder interests
May contribute as a team member
Has a leadership role
Must be available to the Team at any time
1. Agility is all about driving value! Vibhu Srinivasan vibhu@agilefaq.net “Its important to be agile not to do agile”
2. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories What are they . Your role on Agile team. Planning and estimation. Next Steps.
3. Agile ManifeSTO We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
4. Core Values/ Principles Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Commitment Focus Openness Respect Courage
12. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories What are they . Your role on Agile team. Planning and estimation. Next Steps.
13. Product Owner Team AKA Product Definition Team None of us is as smart as all of us – Ken Blachard
14. Scaling ScSScaling rum – Issues Scaling Agile Issues Parallel teams Multiple goals Shared resources Product owners are tasked with carrying the product backlog and be always prepared for all sprint planning meetings.
19. Your PDT is now meeting many times a week 100 Percent Committed ABC– Chief Product Owner XYZ– Area Product Owner AGS– Area Product Owner ADF– Area Product Owner - Area Product Owner. This group clearly are the product managers and own the backlog Around 30 percent Developers ,Testers, architects, UX etc. This group is primarily to help the backlog be more accurate.
20. A few changes !! PDT will keep the various backlogs constantly groomed They own the roadmap , but the teams directly add a realistic view to the roadmap by doing release planning Scrum masters need not have to schedule repeated grooming sessions. The PDT should be doing this. As always this group will inspect and adapt.
21. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories What are they . Your role on Agile team. Planning and estimation. Next Steps.
23. Metascrum Defined Attended by key stakeholders, product definition team, scrum masters and architect and sometimes team members This meeting has a strategic intent unlike the tactical intent of daily scrum. In a Metascrum you discuss where all these features are in flight as compared to the overall roadmap for that group. This is a place to resolve any impediments the teams have not been able to resolve on their own. This group meets every two weeks now on a thursday
24. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories. Your role in your agile team. Next Steps.
26. User story A piece of functionality that is needed to add value to the product. A good story has well defined acceptance criteria. The three C’s of a User Story C = Card C = Conversation C = Confirmation
27. More on user stories User stories bring in the notion of just in time requirements You don’t need use cases. Stories are enough if you have a good product owner. Stories are only complete with acceptance criteria. You can say “NO” to working on stories if the team does not get what the story means. You should give input to the order the stories are built. You may know of dependencies that product owners don’t.
28. Every story you take should pass the invest model test. I – Independent N – Negotiable V – Valuable E - Estimable S - Small T - Testable
29. User story - what it does not have! Technical specifications All the details up front like in a use case or functional specification. Database fields Product owners should tell the “what” not the “how”
30. What about technical stories ? The shiny bunny problem Every sprint the team could buy certain story points to work on technical stories, like enhanced logging, implementing a MVC etc Architects may have some points too for some of their larger initiatives. But always show value in your stories – Write them as abusive stories, word them in a way a product owner will see value.
31. Product Backlog A collection of user stories, well prioritized by the product owner is a backlog Please ask your product owner or your PDT about where your backlog is Backlog never ends, the product owners can choose to ship at any point they see value.
32. “Customers have the right to demand working software but they should respect your estimates”
33. Roadmap and release plan Teams should know what their roadmap is. Ask your product owner where the roadmap is? You should know the product vision, the roadmap, when your next release plan is or where it is?
34. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories. Your role in your agile team. Next Steps.
35. Your role is an agile team What you need is testing not tester. Developing not developer. The shift from I – We – Us is very tough Remember the art of active listening.
36. Your role is an agile team What you need is testing not tester. Developing not developer. The shift from I – We – Us is very tough Remember the art of active listening.
37. Agile team characteristics Self organizing Inspect adapt nature Deliver Frequently Communicate and listen well They believe in testing well. They always can show value in work they do They keep an eye on the baton not the runners.
38. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories. Your role in your agile team. Next Steps.