SWE EPA: AM2 Portfolio Structure | by Esgrid Sikahall

Published on March 21, 2023

Are you ready? The first part of this two-part article gave you some preliminary remarks about the Portfolio and some detailed structure of the discussion. 

This part gives you the Portfolio structure provided by Accelerate People. It should help you create your own template for a piece of evidence in your Portfolio. Make sure that you talk with your coach for feedback and guidance in putting together your pieces of evidence.

Structuring a Piece of Evidence

Each of your Portfolio items should have the following sections:

  1. Overview
  2. Skills Matrix
  3. Behaviour Matrix
  4. Planning
  5. Task Implementation
  6. Results
  7. Knowledge Matrix
  8. Declaration

What should each of those sections include? Let’s have a look.

1. Overview

In this section, you should introduce your work task. You should make sure that you include:

  • Your role in the team
  • Your responsibilities in the team
  • The scope of the task
  • Key performance indicators (what would constitute success? Who are the stakeholders?)
  • And any assumptions about how you tackled the problem

Write a paragraph or two including your role and your responsibilities in the team and make good use of relevant screenshots or diagrams to explain the scope of the task. Business value is measured by how your work directly causes positive change for the stakeholders (for example: reducing the time of tasks and costs, increasing the number of users, etc.). Make sure that you include a description of who they are in your key performance indicators. In the task implementation section below (section 5) you will have a chance to give even more detail on the stakeholders.

2. Skills Matrix

Each piece of evidence should meet some KSBs. There is a specific set of KSBs that must be met in the Portfolio so every piece of evidence should clearly indicate which KSBs are being met. In this section, you should include a matrix of the skills tackled and where they have been tackled (section and page).

ID

Skills

Section, pages

S2

Develop effective user interfaces.

 

S3

Link code to data sets.

 

S5

Conduct a range of test types, such as Integration, System, User Acceptance, Non-Functional, Performance and Security testing.

 

S8

Create simple software designs to effectively communicate understanding of the program.

 

S9

Create analysis artefacts, such as use cases and/or user stories.

 

S13

Follow testing frameworks and methodologies.

 

S14

Follow company, team or client approaches to continuous integration, version and source control.

 

S15

Communicate software solutions and ideas to technical and non-technical stakeholders.

 

S17

Interpret and implement a given design whilst remaining compliant with security and maintainability requirements.

 


In the AM1 article, you can see that the skills not covered here are covered in your work-based project.

As an example, a piece of evidence covering S2 and S17 would include this matrix:

ID

Skills

Section, pages

S2

Develop effective user interfaces.

Planning, 25-29

S17

Interpret and implement a given design whilst remaining compliant with security and maintainability requirements.

Implementation, 30-35

 

3. Behaviour Matrix

Similar to the skills format, the behaviours covered in the Portfolio are in this matrix:

ID

Behaviours

Section, pages

B1

Works independently and takes responsibility. For example, has a disciplined and responsible approach to risk and stays motivated and committed when facing challenges.

 

B4

Works collaboratively with a wide range of people in different roles, internally and externally, with a positive attitude to inclusion & diversity.

 

B5

Acts with integrity with respect to ethical, legal and regulatory ensuring the protection of personal data, safety and security.

 

B6

Shows initiative and takes responsibility for solving problems within their own remit, being resourceful when faced with a problem to solve.

 

B7

Communicates effectively in a variety of situations to both a technical and non-technical audience.

 

B8

Shows curiosity to the business context in which the solution will be used, displaying an inquisitive approach to solving the problem. This includes the curiosity to explore new opportunities, techniques and the tenacity to improve methods and maximise the performance of the solution and creativity in their approach to solutions.

 

B9

Committed to continued professional development.

 

 

The behaviours not covered here are covered in your work-based project.

As an example, a piece of evidence covering B1 and B9 would include this matrix:

ID

Behaviours

Section, pages

B1

Works independently and takes responsibility. For example, has a disciplined and responsible approach to risk and stays motivated and committed when facing challenges.

Planning, 51-57

B9

Committed to continued professional development.

Planning, 52-53

 

4. Planning

In this section, you should include your approach to the task. Make sure you mention:

  • Tools, technology, and techniques used to complete the task and how they fit (or not) the problem you’re trying to solve. If you have a number of options available to you, articulate why you have picked the one you’ve chosen.
  • Any research used to assist you in completing the task and how this research helped you.
  • Any CPD or training you have done in order to complete the task.

5. Task Implementation

In this section, you give the bulk of what you actually did in your task. Include:

  • Information, designs, specifications or code used and its purpose.
  • Any problems encountered or changes made.
  • Any stakeholders, colleagues, or customers engaged with during the task. Make sure you are specific and give sufficient detail on the stakeholders involved - they are, in the end, the ultimate “measure” of the success of your implementation.
  • Mention of legislation, policies, and processes that were followed (where applicable). Evidence of having followed such legislations or policies or processes can be in the form of documents, videos, images, etc.

6. Results

Answer the following questions clearly and add any supporting evidence to make your case. Remember that you can use screenshots, images, etc., to show your results.

  • What was the outcome of your task? 
  • What did you achieve and what would you change in the future? 
  • A very important part of the results is the testimony of the stakeholders and your wider team. Here you should close the stakeholder “circle”: you’ve mentioned them briefly in the overview section (section 1), you’ve expanded on who they are and what you were trying to do for them in the task implementation section (section 5), and finally, in this section, you give evidence of how you met the requirements and the way they’ve responded to your work.

7. Knowledge Matrix

The matrix of knowledge items is as follows:

ID

Knowledge

Section, pages

K1

All stages of the software development life-cycle (what each stage contains, including the inputs and outputs).

 

K3

The roles and responsibilities of the project life-cycle within your organisation, and your role.

 

K4

How best to communicate using the different communication methods and how to adapt appropriately to different audiences.

 

K5

The similarities and differences between different software development methodologies, such as agile and waterfall.

 

K7

Software design approaches and patterns, to identify reusable solutions to commonly occurring problems.

 

K8

Organisational policies and procedures relating to the tasks being undertaken, and when to follow them. For example the storage and treatment of GDPR-sensitive data.

 

K10

Principles and uses of relational and non-relational databases.

 

K12

Software testing frameworks and methodologies.

 

 

The knowledge items not covered here are covered in your work-based project alongside the rest of the skills and behaviours.

A task where you show K1, K5, and K8 would include a matrix like this:

ID

Knowledge

Section, pages

K1

All stages of the software development life-cycle (what each stage contains, including the inputs and outputs).

Planning, 10-15

K5

The similarities and differences between different software development methodologies, such as agile and waterfall.

Implementation, 20-23

K8

Organisational policies and procedures relating to the tasks being undertaken, and when to follow them. For example the storage and treatment of GDPR-sensitive data.

Implementation, 24-25

 

8. Declaration

The assessment plan says that your Portfolio should have a statement from the employer and the apprentice confirming that the evidence is your own work. Accelerate People give an example of this statement.

Apprentice:

I declare this is my own work and is based on a work task that I have carried out during my Apprenticeship and is clearly linked to my job role.

Name:

 

Signature:

 

ULN:

 

Date:

 

Job Role:

 

Manager:

 

 

Employer:

I declare this is a valid work task and the Apprentice has undertaken the task as documented and it has been completed during their Apprenticeship.

Name:

 

Signature:

 

Company:

 

Date:

 

Position:

 

 

Final Evidence Checks

You should review and validate the evidence in your Portfolio against all the KSBs. How do I know if my evidence is suitable or not? The evidence needs to be:

  • Sufficient: The evidence covers all the KSBs assessed in AM2.
  • Authentic: The evidence has been entirely done by you.
  • Relevant: The evidence is relevant to the apprenticeship standard (the pieces of evidence tackle relevant KSBs).
  • Current: The evidence has been completed during your apprenticeship (post-Bootcamp)
  • Consistent: The level of evidence is consistent across all pieces of evidence.

The process of compiling evidence will give birth to your Portfolio. The process goes from writing your piece of evidence; validating it - making sure it checks for everything you need it to check, and going back to the beginning and writing your next piece of evidence:

Index, and High-Level Overview

Your Portfolio is one document containing all your pieces of evidence. Make sure you add a suitable index to this document, referring to each piece of evidence. You could list all the KSBs for each piece of evidence in the index. The idea is to be able to see, at a glance, which tasks met which KSBs.

After the index, add a page where you introduce yourself - your role, your company, and a brief high-level overview of all your pieces of evidence. By now your Portfolio has become a readable map for yourself and for your assessor, making both of your lives easier for your discussion!

Concluding Remarks

…So much to think about! How on earth does one keep track of all of this? Don’t stress. The Portfolio is the largest piece of work you’ll do and it is cumulative work - it should take you approximately a year to write, meaning that you won’t work on “the Portfolio” all at once. You’ll work, instead, on one piece of evidence at a time. Each piece of evidence should be in the format provided above.

Once you have written one, you will have a sense of what you need to do for the next one. Make sure you rely on your coach and your fellow apprentices to fine-tune your pieces of evidence so you develop Portfolio-evidence muscle memory. Also, once you’ve submitted it at Gateway, be in touch with your coach to find ways of practising for your Professional Discussion closer to the date of the discussion. Doing mock discussions with fellow apprentices and family, for example, would help you prepare for the real thing.

From the team of coaches, we wish you all the best in crafting your Portfolio for your Professional Discussion and be sure that we will support you throughout your journey.

Make sure to check out the whole SWE EPA series:

Esgrid Sikahall is a Software Engineering coach at Multiverse.