• UNDERSTANDING OUR METHODOLOGY AND PROCESS

    THE PROUDCLOUD WAY

  • RATES AND TIME FRAMES

    We don't do fixed bid projects. We bill our clients on a monthly Time & Materials basis. Our clients understand that agile projects are very dynamic and constantly changing. It is with this understanding that, as the project features, workload, priorities, and business rules change over time, so do the team delivery estimates and work load.

    TEAM STRUCTURE

    The typical project team is composed of:

    PRODUCT OWNER

    It would be ideal that a single point of contact is assigned to work with the Proudcloud team for sprint planning, story (feature) prioritization, story testing, and story acceptance.

    LEAD PROJECT MANAGER

    He/she will be the Project Manager and SCRUM Master on the Proudcloud side. He/she will help conduct traffic, keep the communication lines open, make sure the project is kept on track, help in avoiding scope creep, and try to ensure that resources are best managed for the timely and successful deployment of the project. He/she is also relied on to rationalize each sprint scope, in consultation with the Product Owner and the engineers.

    SR. ARCHITECT AND DEVOPS ENGINEER

    The lead and senior developer on this project. He/she is an expert in advanced Ruby on Rails and Developer Ops, particularly Amazon Web Services. His/her role is high level supervision and guidance of the rest of the engineering team.

    SOFTWARE ENGINEER

    They will systematically, through SCRUM/XP, complete and deliver the user stories in Pivotal Tracker.

    UI/UX ENGINEER

    Builds the initial wireframes, conceptualizes the UI/UX flow, and style/design elements required by the project.

    QUALITY ASSURANCE

    The Quality Assurance engineer systematically goes through the staging site to ferret out any bugs and usability issues during the development sprints.

    PAIR PROGRAMMING

    We require assigning a development pair to each project as part of our desire to provide good quality code, less technical debt, and accelerate development cycles. To learn more about the practice of Pair Programming and its benefits, you can visit https://leanpub.com/level_up/read

    WORKFLOW

    We employ Agile methods (A hybrid of SCRUM and XP) for all our development projects where;

    • Our development sprints are 10 working days (2 weeks), working days are Mondays to Fridays, and we follow a strict 40-hour work week.
    • A person within the client’s organization will act as Project Owner who will play a keyl role in the definition and continuous evolution of project stories and weekly sprints.
    • The Project Owner will have access to the project management dashboard and the Project Team on Pivotal Tracker (www.pivotaltracker.com) where progress status and feature acceptance can be done in real time.
    • Story acceptance is based on real-time testing on the application available on a staging server.
    • A weekly SCRUM call will be conducted with the Project Owner and the Project Team to review and track current sprints, project issues and backlogs.
    • A daily 10-15 minute standup 'chat' with the Project Owner will be done on Slack to discuss micro-issues on a day to day basis.
    • For a quick introduction to SCRUM, a short but clear video can be found on https://youtu.be/Q5k7a9YEoUI

  • PROJECT MANAGEMENT METHODOLOGY

    Making use of SCRUM and Pivotal Tracker

    01

    THE ICEBOX

    All feature stories and chores start out in the ICEBOX. The team, including the Product Owner, populates this icebox with user stories (features), chores, and bugs at the start, and during the course of the project.

     

    At the start of a sprint, the team decides which stories will be worked on for the duration of the sprint. This is based on the mutual assessment of the team on the complexity and difficulty of the tasks, as well as the prioritization of feature stories.

     

    These stories are then dragged to the BACKLOG for completion and delivery.

     

    Many nice-to-have, but low-value-delivery stories will live in the Icebox until the value to the customer or Product Owner can be reasonably established in the future.

    02

    POINT ESTIMATION AND PROJECT VELOCITY

    SCRUM uses a points system to establish the initial estimation of user stories. At Proudcloud, we have adopted 1 point, 3 points, and 5 points to assign the difficulty level to, and correspondingly the time it will take to finish the user story.

     

    By experience., we have established a rule-of-thumb that equates each point to one (1) man hour of work.

     

    Also, the collective points of the feature stories in the backlog establish the working Project Velocity. Over time and after one sprint has been completed, the actual project velocity is computed and calculated by Pivotal Tracker.

     

    Likewise, the current Project Velocity will affect the delivery timetable of the user stories, and is visible to the entire team, including the Product Owner.

    03

    THE BACKLOG 

    As user stories are completed (delivered) in the BACKLOG, it is now available for the Product Owner to review, test, and accept. It is important for the Product Owner to complete this in a timely manner to keep the velocity calculation as accurate as possible.

     

    This completion, delivery, review, and acceptance of stories continues through out the project. Pivotal Tracker is effective in tracking, taking control of, and reporting the progress of work throughout time.

     

    Any stories that do not fall within the expected action can be rejected, with proper reason indicated in the rejection. The developer team can then revisit the story, make the necessary fixes, and re-deliver it for another round of review and acceptance.

    Cookie Use
    We use cookies to ensure a smooth browsing experience. By continuing we assume you accept the use of cookies.
    Learn More