Download presentation
Presentation is loading. Please wait.
Published byLesley Domenic Barker Modified over 8 years ago
2
#msdevcon Community Track IMPLEMENTATION OF SCRUM Bernardin Katić Insa Investment Software AG
3
Putting it all together
4
Our Scrum project Development/Implementation of our product Product in enterprise LOB solution for banks Scrum (in our way) implemented for the last 5 year internally. Clients use „classical” project management Our client base is in Switzerland/Germany/Italy/Singapore/Panama/Croatia 2 Teams Dev team in Croatia, Sales/Implementation in Switzerland and Singapore 60 customers+ several new every year 4
5
Scrum framework Roles Ceremonies Artifacts Sprint planning Sprint review Sprint retrospective Daily scrum meeting Product backlog Sprint backlog Burndown charts Product owner ScrumMaster Team
6
Scrum Roles 6
7
Product Owner Define features of product Decide Release Date and content Responsible for profitability (ROI) Prioritize features according to market value Adjusts features and its priorities in every iteration Accept or reject work item result One person On vendor side
8
Product Owner Account Manager(s) Contact (filter) to clients Responsible for correct and comprehensive specification and real priorities of change/feature requests Talks to clients BUT always thinks of his team DOES NOT decide alone about which features go into backlog Change Board (App Architect/Key Account Manager/Sales) takes responsibility and decides
9
The Scrum Master Represents Project Management * Enacting Scrum values Ensure team’s productivity Shield team from external interferences Corporate across all roles
10
The Scrum Master 2 scrum teams– 1 scrum master Proxy between 2 teams (development & implementation) Responsible for cooperation between two teams Shield DEV team from external interferences (clients or other team)
11
The team 5-9 members Cross-functional: Programmers, testers, user experience. Full time Work Self-organizing Membership could be changed only between sprints
12
The team(s) 2 Scrum teams Dev team, 6 members, 4 developers, 1 UX, 1 Tester Implementation team, 6 members, 4 Account Managers, 1 Support, 1 Sales Very seldom self-organizing… Taking tasking „out of profile” very welcome but mostly not possible
13
Scrum framework Roles Ceremonies Artifacts Sprint planning Sprint review Sprint retrospective Daily scrum meeting Product backlog Sprint backlog Burndown charts Product owner ScrumMaster Team
14
Daily ScrumSprint PlanningSprint Review Sprint Retrospective Scrum Events
15
The Sprint 30 days or less Reduces risks Creates focus Enables realistic planning
16
The Daily Scrum Parametars Daily 15-minutes Stand-up Not for problem solving Everyone is invited Only team members Scrum Master, product owner can talk Avoiding other unnecessary meetings
17
Not status report for Scrum Master! 3 questions What did I accomplish yesterday? What will I do today? What obstacles are impeeding my progress?
18
The Daily Scrum(s) 2 stand-up meetings, 15 min (max) each, always same time 1st with Implementation Team (Skype – geo-spead team) 2nd with Dev Team (coffee table meeting) Only Scrum Master on both Communication channel between two teams
19
Sprint retrospective Periodically take a look at what is and is not working Typically 15–30 minutes Done after every sprint Whole team participates Scrum Master Product owner Team Possibly customers and others
20
Sprint retrospective Bi-weekly Internal, only Dev Team/Account Manager Clients NOT INVITED Review of priorities for the next sprint
21
The Sprint review Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule No slides Whole team participates Invite the world
22
The Sprint review Monthly For specific customer projects Client is invited Meeting/Demo at clients office Feedback from client
23
Release review Quarterly Announcement to all clients on Yammer/newsletter All clients invited Webcast demo of new features Feedback from clients and implementation/sales/support team
24
Focus Group Yearly Announcement to all clients on Yammer/newsletter All clients invited Organized as held-day workshop (2 hours+ lunch/networking) No more than 15 clients in group Live demo of all new features in the last year Share demo of planned features and further development Proposals & Ideas from clients for the further development Voting, Offline - post-it notes!
25
Scrum framework Roles Ceremonies Artifacts Sprint planning Sprint review Sprint retrospective Daily scrum meeting Product backlog Sprint backlog Burndown charts Product owner Scrum Master Team
26
Product backlog The requirements A list of all desired work on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint
27
Managing the sprint backlog Individuals sign up for work of their own choosing Work is never assigned Estimated work remaining is updated daily Any team member can add, delete or change the sprint backlog Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known
28
50% Strategic Development 30% Feature Requests 20% Incidents/Support Backlog Structure
29
Change Requests Accept only controlled changes Avoid out of scope changes Accept changes – unfortunately this is reality Change requests/Feature Requests Change Control Board Decision about change request(approve, reject, defer) Influence to other customers Code stability analysis Complexity of implementation Business value of the request
30
Scrum Release Management Quarterly Q1, Q2, Q3, Q4 release 6 bi-weekly sprints make one public release Development and Releases versions in parallel All new development in Development track After every sprint Development App version (but internal daily build) Release version fully tested before publishing No new features in Release version Only critical bugs are corrected within Release version Feature set defined for the next release before development starts Feature set defined by change management board Feature set and delivery date announced to clients
31
DEV Q1.100 Branching
32
DEV Q1.108 Q2.1 Q2.100 RELEASE Branching
33
DEV Q1.108 Q2.1 Q2.100 RELEASE Branching
34
DEV Q3.100 Q1.108 Q2.1 Q2.110 Q3.1 RELEASE Branching
35
DEV Q3.100 Q1.108 Q2.1 Q2.110 Q3.1 RELEASE Branching
36
DEV Q3.100 Q1.108 Q2.1 Q2.110 Q3.1 Q2.6 – Patch Q2.17 RELEASE PATCH Branching
37
DEVELOPERTESTER1 ST LEVEL ACCOUNT MANAGER CUSTOMER 5 STEPS TESTING FRAMEWORK Quality Assurance
38
#msdevcon Community Track Questions & Discussion Bernardin Katić bernardin@mscommunity.hr
40
© 2016 Microsoft Corporation. All rights reserved.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.