+ All Categories
Home > Documents > Implementation I - demo. Schedule * Project status -achieving the goals of the iteration -project...

Implementation I - demo. Schedule * Project status -achieving the goals of the iteration -project...

Date post: 17-Dec-2015
Category:
Upload: lee-copeland
View: 215 times
Download: 0 times
Share this document with a friend
Popular Tags:
20
Implementation I - demo
Transcript

Implementation I - demo

Schedule

* Project status-achieving the goals of the iteration-project metrics

* Used work practices* Work results

-presenting the iteration’s results-Demo

* More on work practices (not part of this presentation)

Project description• http://3.bp.blogspot.com/_0arosa8qIkc/SCkQ0fZOliI/AAAAAAAAAz0/i1Wt-UN8a5g/s400/mobile+camera.jpg

Internet

Project stakeholders

Status of the iteration goals

basic functionality – proof of concept

Status of the iteration deliverables

*Updated project plan V*Updated requirements document (no

changes) V *Technical specification V*Updated QA plan V*Test cases, QA report and test log (not applicable yet)* Progress report V

Realization of the tasks

Resource usage

Resource usage after PP

Resource usage after I1

Resource usage

Sampo Toiva

Mikko Porkola

Timo Tuominen

Leo Lännenmäki

Sharmistha Chatterjee

Mohammad Hoque

Markus Yrjölä

Mikko Koski

Iiro Isotalo

0 10 20 30 40 50 60 70 80 90 100

PlannedIteration 1

Used work practices

* Version control: bitbucket.org (Mercurial)

* Continuous integration: Hudson* Weekly meetings -> to two times

per week* Weekly info letter sent by PM* Retrospective meetings held in PBL

style* Sprint planning sessions to be

renewed

Quality issues

www.lumaxart.com

Proof of C

oncept

Quality plans

1. Tests are to be based on user stories

2. Unit tests are planned as tasks during sprint planning

3. Because of proof of concept and prototype building no implemented practices exist at the moment

Risks

General architecture

Mobile architecture

Web UI layout sketch

Demo-

Proof of concept

More on used practicesThe iteration and sprint planning needs more effort. The problems in planning have realized in the communication towards the mentor and the customer. The team has used Agilefant in planning and keeping track of tasks, but the Agilefant tasks have not described properly the current situation of the project. Therefore, the team is introducing the following process regarding the sprint planning:

• 1. The product backlog consists of higher level user stories that can be demoed to the customer. These user stories are split and described more thoroughly in use cases.

• 2. Based on the use cases, the SE-trio will make the initial plans regarding the sprints. The use cases are split into sprint level stories and these further into small tasks that can be demoed in the team meetings.

• 3. After the initial planning is made, the team will keep a sprint planning session and adapt the Delphi-method and estimate the effort the tasks require. Furthermore, new tasks might be created in the planning session if the team sees this appropriate.

• 4. After the estimation, the iteration-level backlog stories are assigned appropriate story points. The story points are also assigned to the appropriate product-level backlog stories.

• 5. Based on the story-points and previous iterations the tasks are chosen that can be implemented in the current sprint.

• 6. The progress is monitored in the weekly meetings with the following definition of ready and done task. The person responsible for a certain task will mark it ready when it can be demoed to the team. The team then decides if the task can be regarded as done. When all the sprint-level story tasks are done, the story is marked done. At the product-level, the stories are marked done when all related lower-level stories are done and the product-level story is demoed to the customer.

More on used practices

*Agilefant is being updated to represent the process described in previous slide. The work has started, but the story points are not yet correctly defined.

More on used work practices

Weekly meetings:The weekly meetings were held once a week. However, this is not enough and during the following sprints the amount is raised to two meetings per week. This is done in order to achieve faster response time to changes and risks.


Recommended