The portfolio should describe real projects you've worked on as part of your job. It should demonstrate how you fulfil the KSBs.
Your portfolio will not be directly assessed. Instead it will be used as the basis of a 60 minute discussion with your assessor, who will ask questions based on the criteria. This format gives you a better chance to show the assessor what you know, since they can ask questions about things that were not fully covered in the portfolio.
Each piece of evidence in your portfolio should be a report describing some work you completed for a project. It is expected that each of these entries will cover multiple KSBs.
For example instead of just describing some tests you wrote for a feature you would describe the entire implementation of the feature, allowing you to demonstrate the testing criteria and several others.
You can think of each entry in your portfolio as a small project write-up. It should describe what you did and include "supporting evidence" like code samples, user stories, work tickets, documentation or other pieces of work, progress reviews, colleague/client feedback, and witness testimonies.
It is suggested that you write evidence and then map to the KSBs after you have finished writing up. This helps to avoid responding directly to KSBs. There's a balance to strike between writing a narrative that describes what you've been working on, and writing documentation relevant to the KSBs.
All the work you include must have been completed for your employer. You cannot include side projects or other non-work activity.
Everything you include must be work that you did. It is okay for the project to have other team members, as long as you are primarily describing work you completed. For example if you implemented a feature but a colleague wrote all the tests for it you would not be able to include the tests as evidence to fulfill the testing criteria.
The evidence should be directly relevant to the KSBs; there is no point describing some work if you can't map it to any of the KSBs. You will be required to submit a mapping document that connects each KSB to the corresponding evidence.
Try to only use "I". The assessor is not interested in what "we" did—they need things to be directly attributable to you.
Your evidence should cover "what", "how", "with whom" and "why". For example: What did you do? How did you do it? How did your role fit into the wider team? Why was the work necessary? Why did you choose the approach you took?
The portfolio "typically contains 10 pieces of evidence". This is a rough measure of how much to include and there's no exact measure for how much you need to write. So far, we've seen portfolios in the range of 5,000 - 15,000 words; there isn't a minimum or maximum word count.
It is important that you have covered every single KSB, at least once. We'd recommend trying to cover each one twice (or more) with your evidence.
For example there are 24 KSBs, so assuming you cover 6 unique ones in each entry you will only need to write about 4 projects.
There is no template for evidence and you might have a different structure for each piece. For example, in one piece of evidence you may have a heading for each stage of the Software Development lifecycle and give detail on how a whole feature was built; in another you may focus only on testing and give detail on different methodologies, frameworks and why you chose to use those.