The document discusses transitioning a project from a traditional waterfall approach to an agile approach. It outlines key aspects of agile methodology including shorter documentation, user stories, iterative planning and development in 2-3 week sprints, collective teamwork, test-driven development, and acceptance testing. The team will focus on delivering working software in iterations rather than extensive upfront documentation and planning.

1. Contents
• Overview of system
• Traditional approach vs Agile approach
• Documentation
• User stories
• Planning phase
• Iteration plan
• Task plan
• Release plan
• Team work
• Design phase
• Testing
• Conclusion
University of Gujrat 1

2. Overview of system
• Hayat is a mobile app which allows users to donate and
request food and objects easily.
• These donations and requests are managed by web app.
University of Gujrat 2

3. Traditional vs Agile approach
• Our project is done through waterfall approach. Where
development of the software flows sequentially from start
point to end point.
• On the other hand agile is all about increments and
iterations.
• It encourages flexible responses to change.
• And now we revamping project according to agile
approach.
University of Gujrat 3

4. Documentation
• While following traditional approach we did a
complete comprehensive documentation.
• Agile states that working software is more
important than long documentation.
• While keeping this in mind our 100 and more
pages’ document can be cut short to only dozens of
pages.
• Instead of document we deliver working system to
customers.
• We depend less on our document and focus more
on working system.
University of Gujrat 4

5. User stories
• Customer writes the few words about requirements
and it is called user story.
Some user stories of project:
• As a user I want to update my profile
• As a user I want to check record of donations
• As a user I want to place donations
• As an admin I want to keep records of riders
University of Gujrat 5

6. Planning phase
• In waterfall model all the planning was done only
once in planning phase before moving to next stage
which is requirement phase.
Project Scheduling:
• Instead of a planning phase, in XP planning is done
at the start of each development cycle which
usually lasts 2-3 weeks (short cycle) this improves
communication between stakeholder and team.
• Dates for meetings and project reviews are fixed
University of Gujrat 6

7. Iteration plan
• An iteration is usually 2-3 weeks in length.
• First using concept of spiking we can get idea of
team’s velocity. (3members)
• A user story with 3 points will be completed in 6
days. If the user story is too long or too short, we
will split it
• Splitting story: As a user I want to place donation
• Users can log in.(3points)
• Users can log out. (3points)
• User can place donation. (4points)
University of Gujrat 7

8. Task plan
• Developer breaks stories into tasks
• Consider stories:
While considering above stories some tasks can be
• UI design of login interface
• UI design of donation form
• Establish connection of login form with firebase
• Review code of donation form
• Test login form
University of Gujrat 8

9. Release plan
• It consists of 6 iterations developer and customer will
choose date for release.
• Customer pick stories and their rough order in which they
want to implement it.
• Stories must be with in velocity
University of Gujrat 9

10. Teamwork
• Instead of allotting one module to each member which we
did previously now all members will work on every task so
each understands the system completely (collective
ownership).
• Rabia,Arooj: UI design of mobile app
• Kashaf,Arooj: Firebase design
• Rabia ,Kashaf: UI design Design Phase
University of Gujrat 10

11. Design phase
• Using traditional approach, we completed design before
implementation the design is final and can’t be change later
while in agile the design in the beginning is kept as simple as
possible.
• Instead of designing whole system we will only focus on the
stories of current iteration.
• keep design simple if login can work with flat files for now
there is no need to design database.
• Code duplication wasn’t considered very much while
following traditional approach but in xp we have to
eliminate duplicate code.
• This can be done by making functions of code which is
needed again and again.
University of Gujrat 11

12. Cont…
Consider in app:
• Header of app is on every page instead of copying header
code on each page we can simply make header component
and import it where required, changes (add new menu, add
new icons/buttons) can be later easily done in header
component instead of doing on each page.
Refactoring:
• As the system is going to change after each iteration and
new features will be added in order to prevent more bugs
and complexity we will refactor.
• we will continuously perform small transformations in code
to improve efficiency without effecting behavior of system,
perform unit tests to make sure everything is working
accordingly.
University of Gujrat 12

13. Testing
• While following traditional approach we performed testing
at the end to check if all requirements meet or not, it makes
bug fixing complicated, but now following xp we will adapt
test driven approach.
Test Driven Development:
• In traditional we wrote code first and then test cases against
that code to test it but now we will write test case first.
these test cases will fail first as there will be no code against
it we will then write code which pass these test cases.
University of Gujrat 13

14. Cont…
Acceptance Tests:
• Only testing is not enough in order to check user stories are
complete we need to write acceptance test which capture
all the details of user stories
• When story will clear all acceptance test only then it will be
considered complete else it will be incomplete and will be
left for next iteration.
• Acceptance test for place donation can be:
• User should be able to place donation from his account
• Only register user should be able to place donation
• User should be able to upload pic of donation And so on
• Story will be only considered complete when all acceptance
tests written against it are passed.
University of Gujrat 14

15. Conclusion
• Agile approach can improve teamwork and help manage
work burden better that traditional approach.
• The working software can help in understanding system
better by both developer and customer.as all the testing is
performed continuously many bugs can be fixed early
avoiding complexities later
University of Gujrat 15