Solving Pain Points with Requirements Alpha
Purpose of the Handout
By following this handout, you will be able to practice the usage of the Essence's kernel on your own. You will continue to help a team figure out where it is.
Pre-conditions
To get the most out of this handout, you should have knowledge of the Essence Alphas, States, and Checklists and you should have read Scenario on Solving Pain Points.
When to apply
The handout describes events that occur after the first release.
Essence Scope
This handout focuses on leveraging the Alpha cards only. Other cards, like Activity Spaces and Competencies are not part of this scenario.
Reference Cards
The Alpha cards used in this scenario are part of the SEMAT kernel.
Solving Pain Points with Requirements Alpha: Scenario 2
Cecile Peraire, Mira Kajko-Mattsson, Barry Myburgh, Maria Augusta Vieira Nelson, Paul E. McMahon
A five-member team has been in charge of developing an online university course management system and has produced the first release. The team has just received the green light from university management to proceed with Release 2.
The functionality in Release 2 would deal with the management of: (1) administrative information, (2) courses, and (3) student performance. It would strongly benefit administrators, faculty members and students, by facilitating their work and communication. It would also benefit university management by decreasing the overall administrative and managerial cost. The management is expecting to see the new system adopted by all at the end of the following academic year.
To further understand the university operation, the team members made inquiries about shortcomings of Release 1. They held frequent meetings with users to identify needs for Release 2, and also observed the usage of the new system. This gave them a good understanding of what worked well and what did not. Results of their efforts were analyzed and the improved usage scenarios were derived and documented at a fairly high level. The team's repository was updated to reflect the changes. Users were kept in the loop to validate the scenarios and to identify their relative importance. UI mockups were then created and/or improved for the most important scenarios. It was agreed that details would still have to be elaborated just before implementation.
In addition to the system users, the team also contacted other stakeholders to take their needs into account. For instance, given the university's current growth projection, the team and university management agreed to assume that the system should accommodate up to 5 000 users. They also agreed that any decisions that had constrained the development of Release 1 would also apply to Release 2.
Dealing with different stakeholder groups turned out to be challenging, as they often had different ideas on how things should be handled. For instance, the way the grades were communicated to the students caused disagreement. Faculty preferred the system to notify students about their grades by emails. Management, on the other hand, preferred the students to log in to access their grades. A short discussion helped solve the problem. Sending grades by emails was against the university's policy and the management solution would have to be implemented.
At some point during Release 2, one team member mentioned that a few faculty members were resisting the migration to the new system. They were still managing communication via emails and course assignments and grades via spreadsheets. They had no intention of migrating to the new system in the future. The team decided to interview a few of these faculty members to find out what the problem was. They also organized a short presentation of the functionality to be implemented in Release 2. The new functionality included (1) the management of student deliverables by the faculty members, (2) the ability to grade and provide feedback to the students, (3) the ability for students to view their grades in the system, and (4) the management of course materials by the faculty members. The goal was also to articulate the value of the new system over the value of the wiki-based solution.
Through the interviews and demonstration, the team realized that the missing features requested by the faculty members were related to the way the new solution computes grades and manages feedback on deliverables. The new system is more restrictive. It does not allow faculty members to associate grading components to each student deliverable and it only supports grades based on points, not on alphabetic symbols.
Solving Pain Points with Team Alpha
Purpose of the Handout
By following this handout, you will be able to practice the usage of the Essence kernel on your own. You will continue to help a team figure out where it is.
Pre-conditions
To get the most out of this handout, you should have knowledge of the Essence Alphas, States, and Checklists and you should have read Scenario on Solving Pain Points.
When to apply
The handout describes events that occur after the first release.
Essence Scope
This handout focuses on leveraging the Alpha cards only. Other cards, like Activity Spaces and Competencies are not part of this scenario.
Reference Cards
The Alpha cards used in this scenario are part of the SEMAT kernel.
Solving Pain Points with Team Alpha: Scenario 2
Maria Augusta Vieira Nelson, Mira Kajko-Mattsson, Barry Myburgh, Cecile Peraire, Paul E. McMahon
A five-member team has been in charge of developing an online university course management system since its first release. The team was formed by the IT director, who carefully chose its members with the purpose of maximizing team productivity. Its composition was based on an optimal mix of personalities with competencies identified as crucial. The team consists of a project manager and four developers, each having the expertise and responsibility in their specific areas such as design, user experience, requirements and database.
The team feels that its size and composition is satisfactory. The members are confident that they have the required competencies to fulfill their responsibilities. They know that as the system grows in the future, the team might have to be expanded.
The team has started working on the second release. It is very well acquainted with the project's initial needs. It has collectively established its goals, mission and responsibilities. The team members agreed to mainly communicate orally and to document only the most important issues such as requirements, design, problems, test cases and important decisions and events. The team practices a democratic leadership style implying that discussions with more than one possible outcome are discussed to make sure that everyone on the team has a chance to impact the decisions.
Team members have worked well and are committed to the project. Communication is sometimes challenging but each member knows how to conduct his/her own work and is dedicated to doing it. This is how the team succeeded in delivering Release 1.
So far, the stakeholder groups that have been identified are Administrators, Faculty, and Students. Each group has a few representatives who are willing to collaborate with the project team. For Release 2, the team has decided to meet and interview faculty members by visiting them at the university. This would help the team to identify needs for Release 2 and observe the usage of the new system.
After the interviews, two developers were in disagreement about one significant requirement. They shared the conflicting viewpoints with the faculty involved. The faculty agreed with the first developer, and the second developer felt somewhat put out that his opinion did not seem to matter. Since this was not the first time that the second developer's ideas had not been accepted, little by little he stopped communicating with the team.