With our last project we got on the scum bandwagon as a way to manage our backlog to keep some method to the madness. Everyone in the team read numerous books, attended various training, and knew how scrum operates. We tried, however fell into the "scum but" category in the end. We recently had a project retrospective and came up with a nice laundry list of things we can do to improve with our next release cycle.

list derived from group discussion

Keep daily stand ups brief

We always had status meetings in the morning which was good to keep everyone on the same page however we tended to diverge in side discussions talking about other areas of the project. This sometimes meant our stand up meetings ended up lasting over 1/2 hour. This quickly relates to our next point.

Team members can leave at the end of the stand up

Many times we would have our standup and then immediately start discussing about other aspects of the project which didn't require everyone to remain in the room. The other team members felt obligated to stay and listen even if they were not required.

List any items that need extra discussion

If extra discussion is required make this a talking point for after the standup. This list allows other team members to see if they need to stay for the extra discussion and if not return to their work area.

External resources should be brought into conversation

Occasionally during our sprint we had tasks handled by external resources such as sever configuration. We treated these as tasks assigned to the person that was responsible to get the task done (by talking to the other group). This resulted in getting second hand knowledge as our team member was a middle man. We now realize these resources should be brought into the sprint and be part of the standup. This makes the resource feel part of the project and is contributing to the success of the sprint.

Do Retrospectives

We did not have many retrospectives during our project which we now know was not ideal. If we would have had these retrospectives we could have addressed some of these findings earlier. Because we did not hold these meetings team members felt frustrated with the process.

Sprint review with owners and stakeholders

This is another area we fell short. We had some very informal and infrequent review with our owners and stakeholders. This resulted in some people not feeling part of the project and questioned some of the decisions made by other stakeholders. We need to increase these reviews and increase transparency so there are no surprises.

Task bugs

After we went live with release one bugs started to come in and our sprint process floundered. We created PBIs for bugs which had no tasks. Things got lost and team members didn't know if the bug was in development, in testing, or even deployed. We needed some tasks to keep track the status of a bug.

Bugs must have a severity

Your bug PBI's need to have a severity. Our post release backlog was filled with bug PBI's of various size and severity but we never gave them a severity or a priority. This resulted in team members working on the bugs in a random order. With the priority we could work on the important ones first and keep the lower priority ones for later in the sprint.

Bugs should include more details

Along with the chaos around a new deployment bugs were added in with details that only made sense at the time. We were in the habit of entering a bug so it would be recorded and not lost but had no detail if it was for one user all users or how to reproduce the issue.

Include Effort for PBI

We had sporadic usage of effort for our PBI's in our backlog. This resulted in quite a few epics in our sprint. It was very demoralizing for the team members working on an epic where they could never cross off their PBI off of the list. We need to add effort to our PBI's so we can identify any potential epics early on and divide up PBI's so they are completed in a sprint.

Keep communication open with the business

This is probably the most important thing we learned. We communicated a lot with team members and individuals involved in our scrum project however we need to increase this communication to all areas of the business. There were a few occurrences where the business didn't understand decisions because they were inadvertently kept out of the loop.

The future

We recently started up our next sprint and hope to take our lessons learned and improve our process in the coming months.