linaro-project-management team mailing list archive
-
linaro-project-management team
-
Mailing list archive
-
Message #00247
Agile Project Management Application message #2 - Key Requirements
Continuing from yesterday's overview message:
Key Requirements Review
A list of requirements from all the project managers is captured in a Google Doc that is open for review. We are would like the application to meet the needs of both the Working Groups and Member Services.
The key requirements are highlighted in Green. A brief description of each follows.
Access Control: Access to projects and data must be controlled particularly for keeping the Landing Team projects in isolation.
Support Agile Scrum type methodology: With our move to an Agile type of methodology, it is important that the tool supports Agile/Scrum. The Landing Teams are starting to work in a Scrum methodology for example.
Support Kanban methodology: We also want some flexibility as the Working Groups or Infrastructure may decide that a Kanban methodology works better for that group.
Support standard browser interface: The easiest way to support a multiple platform environment is to take to the Web.
Support 3rd party tool interface (Launchpad): Probably the make or break deciding factor for the candidates; we want to avoid duplicating work on Launchpad and in the application. The primary use case is to be able to change the status of a work item (or higher level) within the application and see the change on Launchpad or vice versa.
Maintenance is less than 2-4 hours a month: We don't have a resource to manage an installation for a distributed team. So let the vendor host the solution.
A few requirements that are less about the day to day management of the project.
Requirements Management: Ideally, we'd be able to manage and trace requirements from the TSC or a Member's SoW from the same application as we manage the projects.
Rollups: We'd like to be able to roll up status, blockers etc from each group to a program view without having to extract data from spreadsheets.
Cost: Idealistically, we'd like an Open Source solution that doesn't cost anything. There are multiple Open Source/Free applications available with a range of support, features and stability. However, we do know we could go up to $20 per seat per month.
Some open questions:
Besides status, what other data would we want to pass between Launchpad and an application?
Do we have a resource who would be available to either (a) customize an Open Source application or (b) write the integration pipes between Launchpad and the application
Where do we move the arrow on the scale between simplicity/ease of use for a developer/tech lead and more comprehensive functionality (requirements, resource management, program views)?
What other information do we want out of this application? They all will provide burn down charts for example. Reports on blocked tasks? Team velocity or throughput?Requirements or user story status? Dependencies between task or stories?
Feedback is welcome.
Regards,
Vicky Janicki
vicky.janicki@xxxxxxxxxx
Program Director, Member Services Linaro
M: +1.978.319.1661 IRC: vicky Skype: vjanicki Linaro.org│ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Follow ups