1 of 49

Se7en Labs

Project Management 2

Masters in Project Management and Data Science

2 of 49

Table of Content

Team
Business Requirement
Overall of Process
Demo
Challenges and Solutions
Team Performance
Feedback and Q&A

3 of 49

Duygu Ekinci Birol

Data enthusiast

with a design background

Deep Jayesh Vora

Keen interest in data visualization.

Background in I.T.

Multidisciplinary team

Himanshu Dharm

Computer engineer with experience in python and databases

Hina Tanvir

Data analyst , application & database management

Pablo Orrico

Interested in data visualization

background in mechanical engineering

Rashmi Dsouza

Interested in interpreting and analysing data.

Background in corporate law and finance

Tong Chen

Interested in data analyzing. �Background in social science.

Mihir Raut

Intellectual Property Lawyer with a keen interest in data analysis

1. OUR TEAM

4 of 49

2. BUSINESS REQUIREMENTS

SWISS ARMY KNIFE

Calculation of throughput time of products

Calculation of pause intervals of the machine

Short term goal

Rapid execution of experiment

In order to obtain initial results.

Long term goal

Scalability of the app.

Storing data to analyze for further exploration.

Short term goal

Rapid execution of experiment

In order to obtain initial results.

Web based Manufacturing Application

5 of 49

Table of Content

Team
Business Requirement
Overall of Process
Demo
Challenges and Solutions
Team Performance
Feedback and Q&A

6 of 49

DEVELOPMENT TEAM (6 PEOPLE)

PRODUCT OWNER

PROXY PRODUCT OWNER

PRODUCT BACKLOG

SPRINT BACKLOG

STAND UP MEETINGS

REVIEW

MEETINGS

END PRODUCT

SCRUM MASTER

Development

& Test

7 SPRINT

10 DAYS

EACH

SPRINT

Sprint Planning

Stand up Meetings

Sprint Review

& Retrospective

7 of 49

END PRODUCT

All Business Requirements

PRODUCT BACKLOG

SPRINT BACKLOG

Features Scheduled for each Sprint

8 of 49

PROJECT COMPLEXITY

High

Low

Degree of Mission (Novelty)

Degree of Innovation (Technology)

Duygu

Hina

Deep

Tong

Rashmi

Himanshu

Mihir

Pablo

9 of 49

PROJECT COMPLEXITY

High

Low

Degree of Mission (Novelty)

Degree of Innovation (Technology)

Duygu

Hina

Deep

Tong

Rashmi

Himanshu

Mihir

Pablo

10 of 49

Here is summary of the activities that we performed in the initial phases of the project. These activities really helped us kick start the project in the right direction.

We started with the project kick off meeting. We defined Scope for the project which in our cases was ‘Using sensors of the mobile phone via a web application to increase the operational efficiency in the manufacturing Process’.

In addition to scope we also identified various Touch points as well as the end users of our project. The touch points that influence our project are the production line, the machines as well as the developed web application that will be used by the employee monitoring these machines and production lines in saint gobain.

with this overall vision we created a target hierarchy consisting of 4 Epics , where each Epic consists of 1 to 3 number of features. Each feature has user stories and each user story has tasks and sub tasks. The number of user stories and their respective tasks depends on the complexlity of the functionality to be delivered for each sprint.

Aftwards the created user stories user stories are estimated in terms of the prioriy as well as the effort via planning poker and user stories were assigned story points accordingly.

Thereon we moved towards overall sprint planning which has already been explained earlier in the presenattion.

11 of 49

This is the flow chart that represents the PDCA cycle we repeated in every sprint.

We start with the sprint Planning meetings which lasted to about 4 to 5 hours. Tasks are moved from product backlog to sprint backlog , each sprint is assigned a sprint goal in terms of DOD and acc. Criteria

After that capacity is planned in light of the working hours for the whole team. In our sprint each team member had a daily available capacity of ~1.3 working hours excluding weekend. Apart from that we calculated the remaining capacity for each team member after scrum events .

In the same meeting Roles and responsibilities are assigned within the team by the scrum master according to the competency of the team as well as the duration of task estimation which is done via planning poker by the whole team

In the do phase of each sprint , the team is focused on task execution. A daily update meeting of 15 min helps monitor the status/challenges involved in execution of assigned task.

Moreover, the performance of the team is monitored in terms of team velocity and burn down chart

The check phase of each sprint comprises of the review and retrospective , both meetings took about 1 to 2 hours. In review phase Operational readiness of the product is tested by the team accompanied by the integration testing which is done to ensure thet integration of all the nodes involved in the web application platform. Once these test are passed we move towards the customer acceptance which is concluded in each sprint review meeting with the customer.

If the product is accepted it becomes a delivered iterative product for the resp. Iteration, else if not accepted , then it is added back to the product backlog where the whole cycle is repeated again.

After the review meeting retrospective is conducted to reflect upon the lesson learned in each iteration and applying them to the next iterations. In addition to that product backlog refinement is also done in case of any additional requiremnet or any change of requirement from the customer. In the same phase earned value analysis of the project is done to check the deviation of planned person hours from actual person hours.

12 of 49

TARGET HIERARCHY

13 of 49

This is another scrum project management tool that vastly helped us keep track of our execution status of our project. The user stories that were planned to be delivered for the overall project were placed in the product backlog of this task board. In each sprint the respective user stories from product backlog were clustered further into Sprint backlogs keeping into account goals of each sprint. The tasks of user stories passed through the development and testing phases of in Progress status. The completed tasks were moved to done status after functionality or stress testing was successfully conducted by the team. Eventually the backlog items were marked as customer accepted once the deliverables and acceptance criteira for each sprint was accepted by the customer in the sprint review meetings.

14 of 49

Table of Content

Team
Business Requirement
Overall of Process
Demo
Challenges and Solutions
Team Performance
Feedback and Q&A

15 of 49

16 of 49

Table of Content

Team
Business Requirement
Overall of Process
Demo
Challenges and Solutions
Team Performance
Feedback and Q&A

17 of 49

Combination of Project Management and Technical Challenges

Technical Challenges

18 of 49

Buffer time for each app related task in planned capacity

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited knowledge on app development

19 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited knowledge on app development

Selection on Project management tools

Buffer time for each app related task in planned capacity

20 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited knowledge on app development

Selection on Project management tools

Buffer time for each app related task in planned capacity

Dropping the tools that we do not have any experience

21 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

Limited knowledge on app development

Selection on Project management tools

Adaptation to the Agile Mindset

CHALLENGES

SOLUTIONS

Buffer time for each app related task in planned capacity

Dropping the tools that we do not have any experience

Coaching from professor

22 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited information about manufacturing process of Saint Gobain

23 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited information about manufacturing process of Saint Gobain

Research of glass manufacturing industry.

24 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited information about manufacturing process of Saint Gobain

Creating user stories suitable for all the manufacturing processes

Research of glass manufacturing industry.

25 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Limited information about manufacturing process of Saint Gobain

Creating user stories suitable for all the manufacturing processes

Research of glass manufacturing industry.

Constantly adjusting user stories and tasks

26 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

The Absence of Barcode sample

Implementation of different Barcode types in scanning functionality

CHALLENGES

SOLUTIONS

27 of 49

Delayed scanning

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

The Absence of Barcode sample

Delay performance on scan time of the app

Implementation of different Barcode types in scanning functionality

The resolution and pixel type was adjusted to improve scanning time

28 of 49

40% efficiency increase

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

The Absence of Barcode sample

Delay performance on scan time of the app

Overwork by implementation of different barcode types

Implementation of different Barcode types in scanning functionality

The resolution and pixel type was adjusted to improve scanning time

Implementation of most common type (EAN) and used JavaScript to set initial stage

Overlimit in capacity due to mostly technical challenges

29 of 49

SPRINT PLAN

ADAPT

PDCA

DO

CHECK

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

Overlimit in capacity due to mostly technical challenges

30 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Improving web development design according to Figma Design

Drop up button/Production Line

Button shape

Challenges:

Improving web development design according to Figma Design
Integration of front end and back end of app
- conflicts inside development team(designer and coder)
we did not know which part we have to prioritize

solution

- Revising Figma Design to ensure Agility
clarified with customer whether frontend or backend is more important for them.
- improve UI design in multiple iterations

We kept on creating application design and continue development according to the design over each

iteration, We faced conflicts within the design and developer members of the team because it was hard to develop exact figma design on web app specially due to lack of time as well as expertise . Therefore in order to resolve this challenge we ensured agility between design and development and focused on customer prioritization that was a working backend functionality over a good looking application UI

Designer&developer and lack of expertise > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), not fit on figma(lead to communication problems) > stay agile, prioritize customer requirement

31 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Improving web development design according to Figma Design

Drop up button/Production Line

Button shape

Challenges:

Improving web development design according to Figma Design
Integration of front end and back end of app
- conflicts inside development team(designer and coder)
we did not know which part we have to prioritize

solution

- Revising Figma Design to ensure Agility
clarified with customer whether frontend or backend is more important for them.
- improve UI design in multiple iterations

We kept on creating application design and continue development according to the design over each

iteration, We faced conflicts within the design and developer members of the team because it was hard to develop exact figma design on web app specially due to lack of time as well as expertise . Therefore in order to resolve this challenge we ensured agility between design and development and focused on customer prioritization that was a working backend functionality over a good looking application UI

Designer&developer and lack of expertise > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), not fit on figma(lead to communication problems) > stay agile, prioritize customer requirement

32 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Improving web development design according to Figma Design

Drop up button/Production Line

Button shape

Unable to choose which part had to be prioritized.

Challenges:

Improving web development design according to Figma Design
Integration of front end and back end of app
- conflicts inside development team(designer and coder)
we did not know which part we have to prioritize

solution

- Revising Figma Design to ensure Agility
clarified with customer whether frontend or backend is more important for them.
- improve UI design in multiple iterations

We kept on creating application design and continue development according to the design over each

iteration, We faced conflicts within the design and developer members of the team because it was hard to develop exact figma design on web app specially due to lack of time as well as expertise . Therefore in order to resolve this challenge we ensured agility between design and development and focused on customer prioritization that was a working backend functionality over a good looking application UI

Designer&developer and lack of expertise > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), not fit on figma(lead to communication problems) > stay agile, prioritize customer requirement

33 of 49

Backend

Frontend

Design

Development

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Improving web development design according to Figma Design

Drop up button/Production Line

Button shape

Unable to choose which part had to be prioritized.

Prioritizing the tasks that are more important according to clients expectations.

Revising Figma Design to ensure Agility

Implementing Agility in Figma Design & App development design according to prioritized customer requirement

��Prioritizing User Stories / Tasks according to customer requirement��Challenges:

Improving web development design according to Figma Design
Integration of front end and back end of app
- conflicts inside development team(designer and coder)
we did not know which part we have to prioritize

We kept on creating application design and continue development according to the design over each

iteration, We faced conflicts within the design and developer members of the team because it was hard to de

solution

- Revising Figma Design to ensure Agility
clarified with customer whether frontend or backend is more important for them.
- improve UI design in multiple iterations

Designer&developer and lack of expertise > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), not fit on figma(lead to communication problems) > stay agile, prioritize customer requirement

34 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

IMPROVEMENTS

Overall additional requirements from customer:

Production line (Sprint 2)

Downloadable CSV (Sprint 3)

Scan Speed (Sprint 4)

Resolving on unexpected bugs

Fixing similar problems several times

Changing database several times

Next Slides

New requirement from customers such as add product line ,download CSV button, and scan speed, need to change user stories and this requirement

Also, lack of expertise such as UI not fit on figma, hard to create the Drop-up button, fix same problems multiple times and database changes so many times

�Challenges:

there were already too many troubles about backend(trying to improve speed of barcode scanner., lack of expertise), and new user story create more challenges.
One of the tasks could not be completed and had to be moved to next sprint
because of the request for downloadable csv file, we added new user stories to target hierarchy
Two PO’s in one sprint
Pablo (Proxy PO) had completely different time zone
Developers help out with each other when one developer not able to do things
However, as lack of skills , there is only one person takes care backend
Technical part and final presentation need to be prepared in the same time which is hard for everyone

solution

Adding target hierarchy to show that one task is moved to the next sprint

we clarified customers priority first and we requested to drop some user stories in order to finish csv file requirement on time

We had to add additional story points and product backlog was refined where some story points had to be dropped

Solution= at the end the important thing is what client wanted, their request and prioritize them.

-at the end of the sprint we were back on track.

lack of expertise , new requestment , one person take cares backend > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), can’t help

Scrum : Two po and two scrum master

35 of 49

Evolution of System Design

36 of 49

37 of 49

Tool Box

38 of 49

OurTech Stack

Front End

Backend

Database

Software development and version control

39 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

Unable to complete one task

Additional user story

Downloadable CSV file

based on

customer requirement

in Sprint 3

IMPROVEMENTS

CHALLENGES

OUTCOMES

Overall additional requirements from customer:

Production line (Sprint 2)

Downloadable CSV (Sprint 3)

Scan Speed (Sprint 4)

Resolving on unexpected bugs

Fixing similar problems several times

New requirement from customers such as add product line ,download CSV button, and scan speed, need to change user stories and this requirement

��Challenges:

there were already too many troubles about backend(trying to improve speed of barcode scanner., lack of expertise), and new user story create more challenges.
One of the tasks could not be completed and had to be moved to next sprint
because of the request for downloadable csv file, we added new user stories to target hierarchy
Two PO’s in one sprint
Pablo (Proxy PO) had completely different time zone
Developers help out with each other when one developer not able to do things
However, as lack of skills , there is only one person takes care backend
Technical part and final presentation need to be prepared in the same time which is hard for everyone

solution

Adding target hierarchy to show that one task is moved to the next sprint

we clarified customers priority first and we requested to drop some user stories in order to finish csv file requirement on time

We had to add additional story points and product backlog was refined where some story points had to be dropped

Solution= at the end the important thing is what client wanted, their request and prioritize them.

-at the end of the sprint we were back on track.

lack of expertise , new requestment , one person take cares backend > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), can’t help

Scrum : Two po and two scrum master

40 of 49

SPRINT 1

Sprint 5 Backlog

Task 2.1.3.4

Sprint 6 Backlog

Task 2.1.3.4

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Revising target hierarchy by moving uncompleted task to the next sprint

Unable to complete one task

Challenges:

there were already too many troubles about backend(trying to improve speed of barcode scanner., lack of expertise), and new user story create more challenges.
One of the tasks could not be completed and had to be moved to next sprint
because of the request for downloadable csv file, we added new user stories to target hierarchy
Two PO’s in one sprint
Pablo (Proxy PO) had completely different time zone
Developers help out with each other when one developer not able to do things
However, as lack of skills , there is only one person takes care backend
Technical part and final presentation need to be prepared in the same time which is hard for everyone (trueeeee but no good to show I think ? )

solution

Adding target hierarchy to show that one task is moved to the next sprint

we clarified customers priority first and we requested to drop some user stories in order to finish csv file requirement on time

We had to add additional story points and product backlog was refined where some story points had to be dropped

Solution= at the end the important thing is what client wanted, their request and prioritize them.

-at the end of the sprint we were back on track.

lack of expertise , new requestment , one person take cares backend > influence scrum > reason: bc need to change user stories, change sprint , lack of expertise time consuming (influence later planning like drop up button, database handling), can’t help

Scrum : Two po and two scrum master

41 of 49

10 User Stories

13 User Stories

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

CHALLENGES

SOLUTIONS

Additional user story (Downloadable CSV) based on customer requirement in Sprint 3

Revising product backlog by readjusting uncompleted user stories

Challenges:

there were already too many troubles about backend(trying to improve speed of barcode scanner., lack of expertise), and new user story create more challenges.
One of the tasks could not be completed and had to be moved to next sprint
because of the request for downloadable csv file, we added new user stories to target hierarchy
Two PO’s in one sprint
Pablo (Proxy PO) had completely different time zone
Developers help out with each other when one developer not able to do things
However, as lack of skills , there is only one person takes care backend
Technical part and final presentation need to be prepared in the same time which is hard for everyone

solution

Adding target hierarchy to show that one task is moved to the next sprint

we clarified customers priority first and we requested to drop some user stories in order to finish csv file requirement on time

We had to add additional story points and product backlog was refined where some story points had to be dropped

Solution= at the end the important thing is what client wanted, their request and prioritize them.

-at the end of the sprint we were back on track.

42 of 49

Planned:

Project Duration:62 days

Total Story points: 704

Average Team velocity: 13.2 SP/day

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

Speaker notes for the slide.

In the Do phase of our PDCA cycle repeated per iteration, we continuously evaluate the performance of team via burn down chart. This gives up a picture of how many SPs we burn daily vs the total number of days in which the project will be completed. In this slide we show the burn down chart of our project.

The total story points to be completed for our project were 704 SPs, these had to be delivered in 62 days.

According to Forecast line (as seen in blue) the average velocity of the team in which it burn SPs per day is 13.2 SPs/day.

However actual progress of the project is different than Forecasted . There are the deviations from forecast represented by solid grey line in As is burn down. As well as there are additional SPs added from the customer shown by the yellow line. On basis of these two measures the dotted line ( Linear regression (As-is Burn Down) keeps on changing depending on the actual Percentage of completion (PoC) of the project. If we see this graph we have major deviations in the days 33 to 43 in Sprint 5 as well as new efforts from the customer,

This analysis helped us see in advance that the initially planned Sps will be delivered in a duration of 66 days instead of 62 days. Therefore, in we take advantage of our Agile Scope Flexibility and reduce the number of SPs to be delivered form 704 to 654 SPs

Explanation of Graph for understanding.

Our project lasted for 62 days. With a total of 704 SP to be delivered, We acquired a velocity of completing ~ 13.2 SPs/day on average

The blue line in the chart represents Forecast. Forecast is an estimation of story points burned according to velocity of previous iterations.

On the other hand the number of SPs we actually complete in a day are different than the planned. To measure that we use ‘Finished SP’ presented by the orange line in the graph

From Finished SP’s we create an As-is Burn Down. As-is Burn Down (the solid line in grey) shows the SP burned actually per day through the cours of project or in other work the Actual Percentage of completion of the project. The point worth noting is the deviation of this line from the planned Forecast line occurring around the iteration of sprint 5.

At the same time all the Additional story points from the customer are plotted by the yellow line of New effort.Yellow line

Because of the new effort (Additional story points from the customer) and As is burn down (SP actually burned per day) we perform new calculation of velocity that is shown by the slope of Linear regression (As-is Burn Down). Linear regression (As-is Burn Down) is the best fit regression that can be shown as a dotted line grey line. This keeps on changing according to the actual percentage of completion of our project. Since we had new story points added from the customer as well as the percentage of completion of the project was deviated than the planned , the point of intersection of the best fit regression line is shifted from 62 days to 66 days as can be seen in the graph.

Therefore we reduce the number of story points that we plan to deliver

Instead of 704 Sp we deliver 654 SPs to match the Forecast.

43 of 49

Planned:

Project Duration:62 days

Total Story points: 704

Average Team velocity: 13.2 SP/day

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

10 User Stories

13 User Stories

Actual:

Fixed Project Duration:62 days

Revised Total Story points: 654

Speaker notes for the slide.

In the Do phase of our PDCA cycle repeated per iteration, we continuously evaluate the performance of team via burn down chart. This gives up a picture of how many SPs we burn daily vs the total number of days in which the project will be completed. In this slide we show the burn down chart of our project.

The total story points to be completed for our project were 704 SPs, these had to be delivered in 62 days.

According to Forecast line (as seen in blue) the average velocity of the team in which it burn SPs per day is 13.2 SPs/day.

However actual progress of the project is different than Forecasted . There are the deviations from forecast represented by solid grey line in As is burn down. As well as there are additional SPs added from the customer shown by the yellow line. On basis of these two measures the dotted line ( Linear regression (As-is Burn Down) keeps on changing depending on the actual Percentage of completion (PoC) of the project. If we see this graph we have major deviations in the days 33 to 43 in Sprint 5 as well as new efforts from the customer,

This analysis helped us see in advance that the initially planned Sps will be delivered in a duration of 66 days instead of 62 days. Therefore, in we take advantage of our Agile Scope Flexibility and reduce the number of SPs to be delivered form 704 to 654 SPs

Explanation of Graph fro understanding.

Our project lasted for 62 days. With a total of 704 SP to be delivered, We acquired a velocity of completing ~ 13.2 SPs/day on average

The blue line in the chart represents Forecast. Forecast is an estimation of story points burned according to velocity of previous iterations.

On the other hand the number of SPs we actually complete in a day are different than the planned. To measure that we use ‘Finished SP’ presented by the orange line in the graph

From Finished SP’s we create an As-is Burn Down. As-is Burn Down (the solid line in grey) shows the SP burned actually per day through the cours of project or in other work the Actual Percentage of completion of the project. The point worth noting is the deviation of this line from the planned Forecast line occurring around the iteration of sprint 5.

At the same time all the Additional story points from the customer are plotted by the yellow line of New effort.Yellow line

Because of the new effort (Additional story points from the customer) and As is burn down (SP actually burned per day) we perform new calculation of velocity that is shown by the slope of Linear regression (As-is Burn Down). Linear regression (As-is Burn Down) is the best fit regression that can be shown as a dotted line grey line. This keeps on changing according to the actual percentage of completion of our project. Since we had new story points added from the customer as well as the percentage of completion of the project was deviated than the planned , the point of intersection of the best fit regression line is shifted from 62 days to 66 days as can be seen in the graph.

Therefore we reduce the number of story points that we plan to deliver

Instead of 704 Sp we deliver 654 SPs to match the Forecast.

44 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

Deviation in Sprint 5

Deviation in Person Hours : ~ > 6 %

Earned Value for Project: ~ < 8%

Budgeted Cost for Work Scheduled (BCWS): 704
Actual Cost of Work Performed (ACWP): 659
Budgeted Cost for Work Performed (BCWP): 654

In addition to evaluating the velocity of team we keep on monitoring the earned value of our project as well. This is the EVA chart of our project. With the help of this we keep track of the deviations in terms of Person hours planned for the project and the person hours actually invested in the project as well as the earned value in terms of Actual PoC of project.

The chart shows some minor deviated in Planned vs Actual value of the project throughout the project. However some major deviations are seen during the time window of Sprint 5 where we are spending more than 6 % person hours than we actually planned , Meanwhile we are lagging behind upto ~8 % in terms of actual Percentage of completion of the project. Eventually we overcome the deviation by delivering lesser SPs than actually planned and shift nearer to the planned line in the spirit of Agile delivery .

45 of 49

Table of Content

Team
Business Requirement
Overall of Process
Demo
Challenges and Solutions
Team Performance
Feedback and Q&A

46 of 49

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

SPRINT 6

SPRINT 7

Duygu

Hina

Deep

Tong

Rashmi

Himanshu

Mihir

Pablo

Team performance

Overall performance of 8 independent people

Collective mind

CHALLENGES

Team members were absence

Team members had completely different time zone

47 of 49

Product Handover

Handover Document: Link

Quality Assurance Documentation

Source Code

Technical Documentation including user guide

Links to App and API

48 of 49

Possible Next Steps

User Authentication

Functional Search Bar

Functional Gyroscope and Accelerometer

Offline Functionality

MQTT Protocols

49 of 49

THANK YOU!

FEEDBACKS AND QUESTIONS

#StayAgile