Sprint 9 Retrospective, Project Close-Out

[DeeMcCart]

EPIC: Agile

Assumptions:

• Following agile methodology for this project
• Closing out (weekly) sprint should be done with a retrospective
• Today 23/11/23 is end-of-project (or, more accurately, end of Release1 as it is intended to progress this software project further, outside the academic environment)
• Therefore Sprint9 is ending midweek and there is no Sprint10 scheduled

Acceptance Criteria

• Sprint9 closed off (will happen automatically at end of week in any case)
• Any issues or part-issues which were linked to Sprint9 but not in 'Done' status reviewed
• Incomplete items labelled either as 'won't do' or as a future backlog item
• Issue log tidied up

Tasks

• [x] Task1 Retrospective
• [x] Task2 Closeout

[DeeMcCart]

SPRINT9 RETROSPECTIVE:

To much to do, and with a tight deadline!

Sprint8 has been very busy with lots of small achievements. A record 79 SPs worth of tasks moved into 'done' status during ths sprint, despite it being only 4 days in duration. This can be seen at SPs per Sprint, by Label.

48 SPs were could-haves and 31 were must-haves. Key functionality that was put into place last-minute were things like the HTTP error pages, and the content-search capability. An observation was made that the About- Feedback page is not really needed for a content-hosting site as that content can actually sit within a master Article, and feedback can be delivered via the Respond (Comments) facility against that Article. That way, the administrator can receive the feedback (while following normal comment moderation), and can publish if appropriate.

Similarly a READme Features document was created, and it is promoted to users as a 'help' or 'how to ' document for the site. So a content management site can be delivered slightly differently to a specific-purpose app.

The number of SPs per sprint may reflect that some issues had been part-completed in a previous sprint then returned to Backlog, therefore a more accurate measure of time is this insight graph: Time-taken by Sprint, per EPIC This shows 63 hours logged which is probably accurate for this week.

Time trade-offs were necessary this week. I realised that meaningful content needed to be created in order for users (even testing users) to engage with the site, so some time was spent on this also. In doing so I was repeatedly testing the site functionality, so it was not wasted time (I regard it as time invested in the next release!!)

However it did mean that the overall READme suffered and was not delivered to the quality I would have liked.

It's possibly a lesson learned about creating a content management site. Another observation is that my READme possibly suffered as, rather than keeping the READme up to date as I went along, which would be by usual approach, a lot of project documentation was captured here on the Agile board. Maybe for the next project I'd put a task 'Comb the Agile Board for stuff that belongs in READme'