Unit 14: Collaborative Project Planning and Monitoring using GitHub and Asana - Subjective Questions

GitHub supports software project management by combining source-code management, collaboration, requirement tracking, and progress monitoring in one platform.

• Repositories: Store source code, documentation, configuration files, and project history.
• Issues: Represent requirements, defects, change requests, and development tasks.
• Labels: Categorize issues by priority, type, component, or status.
• Milestones: Group issues and pull requests under a release, sprint, or project phase.
• Branches and pull requests: Support parallel development and controlled code review.
• Project boards: Visualize work using workflows such as To Do, In Progress, and Done.
• Actions: Automate testing, builds, deployment, and status checks.
• Insights: Provide information about contributions, issue completion, and repository activity.

Thus, GitHub creates traceability from a requirement or issue to its implementation, review, testing, and release.

A GitHub Issue can represent a functional requirement, non-functional requirement, user story, defect, enhancement, or technical task.

A requirement issue should contain:

• A clear and unique title.
• A detailed requirement description or user story.
• Acceptance criteria that define completion.
• Relevant labels such as requirement, high-priority, or security.
• An assignee responsible for implementation.
• A milestone representing the planned release or sprint.
• Links to related issues, documents, commits, and pull requests.

During development, comments and status changes provide a history of discussions and decisions. A pull request may reference the issue using keywords such as Closes #25, causing the issue to close automatically after the pull request is merged. This establishes end-to-end traceability between the requirement and the implemented code.

A requirement-oriented GitHub Issue template may contain the following fields:

• Requirement ID: Provides a unique reference, such as REQ-014.
• Title: Gives a short and meaningful summary.
• Description: Explains the required behavior or business need.
• User story: Uses a format such as: As a user, I want a feature so that I receive a benefit.
• Acceptance criteria: Lists measurable conditions that must be satisfied.
• Priority: Indicates urgency, such as high, medium, or low.
• Dependencies: Identifies requirements or tasks that must be completed first.
• Assignee: Specifies the person responsible for delivery.
• Milestone: Connects the requirement to a sprint or release.
• Attachments or references: Links mock-ups, specifications, or external documents.
• Definition of Done: States review, testing, documentation, and deployment expectations.

A standardized template improves consistency, completeness, estimation, review, and traceability. It also reduces ambiguity because every requirement is documented using the same structure.

The repository can be created and managed through the following steps:

1. Create the repository: Select a repository name, description, visibility, and owner.
2. Initialize it: Add a README.md, an appropriate .gitignore, and a software license.
3. Clone the repository: Team members use git clone to create local copies.
4. Define access: Add collaborators or teams and assign suitable permissions.
5. Protect important branches: Require pull-request reviews, successful checks, and restricted direct pushes to the main branch.
6. Establish conventions: Define naming rules for branches, commits, issues, and releases.
7. Organize work: Create labels, milestones, issue templates, and project boards.
8. Enable automation: Configure continuous integration, tests, builds, or deployment through GitHub Actions.
9. Maintain documentation: Update setup instructions, contribution guidelines, and architecture information.
10. Monitor activity: Review issues, pull requests, security alerts, contributors, and repository insights.

Good repository management provides security, consistency, controlled collaboration, and a reliable history of the project.

Labels and milestones serve different but complementary purposes.

Labels:

• Categorize issues and pull requests.
• An item can have multiple labels.
• Common label dimensions include type, priority, component, and status.
• Examples include bug, feature, urgent, frontend, and blocked.

Milestones:

• Group issues and pull requests toward one larger objective.
• Usually represent a sprint, release, phase, or delivery target.
• May have a due date and a description.
• Display completion progress based on open and closed items.

For example, a payment defect may have the labels bug, high-priority, and backend, while being assigned to the Version 2.0 milestone. Labels explain what kind of work it is, whereas the milestone explains when or for which objective it is planned. Together, they support filtering, prioritization, release tracking, and reporting.

• A commit is a recorded snapshot of changes in a repository. It contains an identifier, author, timestamp, message, and reference to previous history.
• A branch is an independent line of development. It allows a feature, fix, or experiment to be developed without immediately changing the main branch.
• A merge combines changes from one branch into another branch.

In a collaborative workflow, a developer creates a branch from the latest main branch, edits files, and records logical changes as commits. The branch is pushed to GitHub, and a pull request is opened. Team members review the code and automated checks are executed. Once the changes are approved, the feature branch is merged into the main branch.

This relationship enables parallel development, change isolation, review, rollback, and a traceable project history.

A feature-branch workflow isolates each change in a separate branch and integrates it through review.

1. Create or select a GitHub Issue describing the work.
2. Update the local main branch using git pull.
3. Create a branch such as feature/user-login.
4. Implement the feature and make small, meaningful commits.
5. Push the branch to GitHub.
6. Open a pull request and link it to the relevant issue.
7. Allow automated tests and quality checks to run.
8. Request review from appropriate team members.
9. Address comments by pushing additional commits.
10. Merge the pull request after approval and successful checks.
11. Delete the completed feature branch and close the linked issue.

Pull requests provide a controlled place for discussion, comparison, testing, approval, and documentation. Code reviews improve quality by detecting defects, enforcing standards, and sharing knowledge before the change enters the main codebase.

A merge conflict occurs when Git cannot automatically combine changes, usually because two branches modified the same lines or one branch deleted a file modified by another.

A safe resolution procedure is:

1. Update local branch information using git fetch or git pull.
2. Merge or rebase the target branch into the working branch.
3. Use git status to identify conflicted files.
4. Open each file and inspect Git conflict markers.
5. Consult requirement owners or the other developer when the intended behavior is unclear.
6. Edit the file to retain the correct final content and remove conflict markers.
7. Stage the resolved files using git add.
8. Complete the merge with a commit or continue the rebase.
9. Build the software and run all relevant tests.
10. Push the resolved branch and allow reviewers to inspect the result.

Conflicts should not be resolved merely by selecting one side. The developer must understand both changes and verify that the combined behavior satisfies the requirements.

An Asana workspace is a shared collaboration environment containing members, teams, projects, and organizational information. It defines the broader area in which users cooperate and controls membership and access.

An Asana project is a structured collection of related tasks created to achieve a particular objective, such as developing a mobile application or delivering a release. A project may be viewed as a list, board, calendar, or timeline.

They support collaborative planning by enabling teams to:

• Centralize tasks, discussions, files, and deadlines.
• Group work by product, department, sprint, or client.
• Assign ownership and make responsibility visible.
• Define sections, milestones, dependencies, and custom fields.
• Share status updates with stakeholders.
• Track work through multiple visual views.
• Control whether a project is private or accessible to a wider team.

The workspace provides the organizational boundary, while projects provide the operational structure for planning and tracking specific outcomes.

An Asana project can be configured as follows:

1. Choose the workspace or team: Select the correct organizational location.
2. Create the project: Start from a blank project or use a software-development template.
3. Name and describe it: State the project goal, scope, deliverables, and communication rules.
4. Select a default view: Use list, board, calendar, or timeline according to team needs.
5. Add members: Include developers, testers, managers, and relevant stakeholders.
6. Define sections or stages: Examples include Backlog, Planned, In Progress, Testing, and Done.
7. Create tasks and subtasks: Break deliverables into actionable work items.
8. Assign ownership and dates: Give each task a responsible assignee, start date, and due date.
9. Add dependencies and milestones: Represent sequence constraints and key achievements.
10. Create custom fields: Record priority, status, complexity, component, or estimated effort.
11. Configure rules: Automate routine actions such as moving completed tasks.
12. Review views and permissions: Verify timeline feasibility, workload, visibility, and editing rights.

The result should provide every team member with a clear view of what must be done, by whom, and by when.

A task represents a significant, actionable unit of work with its own owner, deadline, description, attachments, and status. A subtask breaks a parent task into smaller activities required to complete it.

For example, the task Implement user authentication may contain subtasks for designing the login interface, implementing the API, creating database changes, writing unit tests, performing security testing, and updating documentation.

Useful decomposition guidelines include:

• Each work item should have a clear action and expected output.
• Assign one accountable owner to each task or subtask.
• Keep items small enough to estimate and monitor.
• Separate activities that require different skills or owners.
• Include acceptance criteria and completion evidence.
• Avoid excessive nesting that hides project visibility.
• Add dependencies where sequence matters.
• Use milestones for important outcomes rather than ordinary activities.

Effective decomposition improves estimation, accountability, progress reporting, and early identification of blocked work.

A task dependency indicates that one task is waiting for another task to be completed. The predecessor is the blocking task, while the successor is the blocked task.

For example, system testing may depend on completing development and deploying a test build. Dependencies affect scheduling in several ways:

• They define the logical order of activities.
• They reveal blocked tasks and prevent premature execution.
• A delay in a predecessor may shift the successor and later tasks.
• Chains of dependent tasks can identify schedule-sensitive work.
• They help managers evaluate the effect of requirement or resource changes.

A team should first list tasks, estimate durations, and identify predecessor-successor relationships. These relationships should then be displayed in the Timeline view. If a critical predecessor is delayed, the manager may reassign resources, overlap safe activities, reduce scope, or revise dates.

Dependencies must reflect genuine constraints. Unnecessary dependencies reduce flexibility, while missing dependencies create unrealistic schedules and coordination failures.

Effective responsibility assignment and deadline setting should follow these practices:

• Give each task one accountable assignee to avoid confusion over ownership.
• Mention collaborators in the task description or comments when several people contribute.
• Match tasks with the assignee's skills, role, availability, and authority.
• Provide a clear description, acceptance criteria, priority, and required attachments.
• Set realistic start and due dates using effort estimates, dependencies, and resource availability.
• Include review, testing, and approval time rather than scheduling only implementation.
• Avoid assigning all tasks the same deadline because this hides the actual sequence.
• Use intermediate milestones for long projects.
• Review the Workload view to prevent over-allocation.
• Notify stakeholders early when a deadline is at risk.
• Reassess dates when scope, assumptions, or dependencies change.

A deadline should be a credible planning commitment rather than an arbitrary date. Clear ownership and realistic dates improve accountability and schedule predictability.

The Timeline view displays tasks along a time axis and provides a visual representation similar to a Gantt chart.

It can be used to:

• Display task start dates, due dates, and durations.
• Show overlapping and sequential work.
• Connect dependent tasks.
• Identify schedule gaps, bottlenecks, and unrealistic date combinations.
• Visualize milestones and major releases.
• Drag tasks to reschedule work when plans change.
• Assess the downstream effects of a delayed predecessor.
• Communicate the schedule to team members and stakeholders.

To maintain the schedule, the project manager should ensure that major tasks have dates, validate dependencies, compare actual progress with planned timing, and update the timeline after approved changes. The team should regularly review overdue, blocked, or tightly linked tasks.

The Timeline view improves schedule understanding, but its accuracy depends on current task data. Missing dates, incorrect dependencies, and outdated status information can produce a misleading plan.

The Workload view shows how work is distributed among team members over a selected time period. It supports resource management by comparing assigned work with each member's available capacity.

Managers can use it to:

• Identify over-allocated and underutilized team members.
• Examine workload by task count, estimated hours, points, or another effort field.
• Reassign tasks to balance demand across the team.
• Delay or split non-critical work when capacity is exceeded.
• Detect future resource shortages before they affect delivery.
• Consider leave, parallel projects, and specialized skills.

For example, if one developer has 45 estimated hours in a week but has only 30 hours of project capacity, the overload is 15 hours. The manager can redistribute work, change the schedule, reduce scope, or add resources.

Workload data should be interpreted carefully because equal task counts do not imply equal effort. Reliable utilization decisions require realistic effort estimates and updated assignments.

Project monitoring in Asana should combine task-level information with project-level status reporting.

Task-level monitoring includes:

• Reviewing completed, in-progress, blocked, and overdue tasks.
• Checking assignees, due dates, dependencies, and recent comments.
• Updating custom status fields and completion percentages where appropriate.
• Verifying that completed tasks satisfy their acceptance criteria.

Project-level status updates should summarize:

• Overall health, such as on track, at risk, or off track.
• Work completed during the reporting period.
• Upcoming milestones and deadlines.
• Major blockers, risks, and decisions required.
• Schedule or scope changes.
• Actions and owners for resolving problems.

Dashboards, Timeline, Workload, milestones, and saved reports can reveal trends. Status updates should be regular, evidence-based, concise, and visible to stakeholders. An incomplete task should not be marked complete merely to improve statistics, because accurate information is essential for corrective action.

GitHub is primarily centered on software artifacts and development workflows, whereas Asana is centered on work planning, scheduling, ownership, and resource coordination.

GitHub strengths:

• Direct connection between issues, commits, branches, pull requests, and releases.
• Strong source control and code-review capabilities.
• Automated testing and deployment through GitHub Actions.
• Detailed technical traceability.

Asana strengths:

• Structured task and subtask planning.
• Explicit dependencies, start dates, and deadlines.
• Timeline-based schedule visualization.
• Workload analysis across people and projects.
• High-level status communication for technical and non-technical stakeholders.

Both tools support assignments, comments, deadlines, attachments, and status tracking. GitHub is generally more suitable for managing code-related execution, while Asana provides broader schedule and resource visibility. When used together, GitHub can remain the authoritative source for development activity, while Asana coordinates cross-functional plans and major deliverables. Clear ownership rules are necessary to prevent duplicate or inconsistent task data.

An integrated release workflow may be designed as follows:

1. Define the release goal in Asana: Create a project, release milestone, target date, and high-level deliverables.
2. Plan the schedule: Add tasks, owners, dependencies, and dates; then validate them in Timeline and Workload views.
3. Create technical work in GitHub: Record requirements, defects, and engineering tasks as Issues with labels, assignees, and a release milestone.
4. Link the systems: Add GitHub Issue or pull-request links to corresponding Asana tasks. Where supported, use integrations or automation to synchronize status.
5. Implement through branches: Create a feature branch for each significant issue and record meaningful commits.
6. Review through pull requests: Link pull requests to issues, execute automated tests, and obtain approvals.
7. Monitor execution: Use GitHub for technical progress and Asana for dependencies, deadlines, workload, and cross-functional activities.
8. Manage changes: Record scope changes, evaluate schedule impact, and update both tools where relevant.
9. Prepare the release: Complete testing, documentation, deployment, training, and approval tasks.
10. Close and review: Merge approved code, close issues, complete the release milestone, update project status, and record lessons learned.

The team should define which tool is the authoritative source for each data type. For example, code status belongs in GitHub, while resource capacity and cross-team deadlines belong in Asana.

Useful indicators include:

• Issue completion rate: Number of issues closed during a reporting period.
• Milestone completion: Proportion of milestone items that are closed.
• Pull-request cycle time: Time from opening a pull request to merging it.
• Open defect count: Number of unresolved defects, grouped by severity.
• Overdue task count: Number of Asana tasks past their due dates.
• Milestone adherence: Whether major outcomes are completed by planned dates.
• Blocked task age: Time for which tasks remain blocked.
• Workload variance: Difference between assigned effort and available capacity.
• Schedule variance: Difference between planned and actual completion dates.
• Rework rate: Number of reopened issues or tasks requiring repeated correction.

These measures must be interpreted in context. Closing many small issues does not necessarily represent more value than completing one complex requirement. Milestone percentages may ignore differences in task effort. Commit counts are particularly weak productivity measures because commit size and purpose vary greatly. Metrics should therefore support discussion and corrective action rather than individual ranking. Combining quantitative indicators with risk reviews and qualitative status updates provides a more reliable assessment.

A requirement change should follow a controlled and traceable workflow:

1. Record the request: Create a GitHub Issue or formal change item describing the proposed change, rationale, and requester.
2. Analyze impact: Identify affected requirements, source files, tests, documentation, tasks, dependencies, cost, and schedule.
3. Review and approve: Obtain a decision from the product owner, project manager, or change-control authority.
4. Update planning information: Modify relevant Asana tasks, dates, dependencies, responsibilities, milestones, and project status.
5. Categorize the technical work: Apply suitable GitHub labels, priority, assignee, and release milestone.
6. Implement in a branch: Reference the change issue in commits and the pull request.
7. Verify the change: Execute reviews, automated tests, acceptance tests, and regression tests.
8. Update documentation: Revise specifications, user guides, and release notes.
9. Close linked records: Merge the approved pull request, close the GitHub Issue, and complete the related Asana task.
10. Preserve history: Retain discussions, approvals, links, and decision reasons for auditing.

This procedure maintains traceability from the original change request through impact analysis, planning, implementation, testing, and release.