christianstivactas

Retrospectives can be repetitive for well established agile teams, especially when you are in your 27th sprint (54 weeks). So it is important for the Scrum Master to come up with ideas to make these ceremonies which sometimes feel mundane and turn them into enjoyable sessions for the team to increase engagement and excitement. This idea was given to me by a colleague of mine which allowed me to start thinking more creatively. In honour of me leaving the organisation she created a retrospective in theme of my new organisation. This was such an awesome spin on our existing retros I thought "why stop there?". So in collaboration with her we have started a collection of themed retrospectives for all teams to use and contribute to. We call it "RetroThemez" and it can be found on github here . https://github.com/cs91/RetroThemez  The flow of the retrospective follows the following structure: Team shout outs What went well? What needs improvement? How can we ...

So before I wrote this post I did a quick google search to figure out what people believe a"Rainbow Sprint" is and it is completely different to what I originally thought so lets change that shall we. What I coin a "Rainbow Sprint" is "a sprint that contains multiple epics or team objectives that have been agreed in sprint planning". Why is this important you ask? Well I bring this topic up as it is very easy for agile scrum teams to be in 110% feature mode and not be able to provide value to other areas of the team's responsibilities. For example the scrum team have been allocated multiple features to deliver into production, let's call them feature "Green" and feature "Red". Priorities based on value and capacity do not allow the team to also have some tech debt "Blue" to close out and not to mention are wanting to continuously work on their automation framework "Purple". Rainbow sprints are another...

I recently had a question about how we track agile delivery in the team I currently work in. Let's all agree up front there is some rigidity to agile delivery and project work that we all do in the digital & technology space. Usually a project goes like so, there is a product vision, we agree the features we want to deliver for a first release (MVP) and then build on it iteratively from there. This creates a sense of scope, we then try to estimate a timeframe for this and from there we kick-off development. In some of my previous posts I have explained details around Agile Estimation P1 and P2  which is up front estimations to gain an idea of release effort and time. However in this post we go into a bit more detail about real-time projection and transparency of teams. The example I will use today is building a new front-end customer facing platform. This can take some time and the team have estimated up front potentially how long it might take them. Let's fast-forward...

We've all heard the phrases INVEST and SPIDR (or maybe not, I didn't know about SPIDR until two weeks ago) but there are certain techniques that can make an effective user story. I don't want to focus too much on how to split user stories, but more so how I believe a well elaborated user story may look after working with various team members. I have a set template ( found here ) that I tend to always use and seems to work well with my teams. The scenario that we will talk through today will be a customer wanting to login to their portal using their mobile phone number. House keeping table Who are the various stakeholders? What is the reference number? (JIRA) This provides a context of who the collaborators of the story were/are and how we can navigate the land of JIRA. User Story Your usual format of "As a...I want...So that..." Who is the user? (As a),  What are we building? (I want) What is the value (So that) As a customer I want to prov...

In my opinion a retrospective is one of the most valuable ceremonies that you can bring to a agile delivery team. The aim is to reflect on the last sprint usually two week cycle of agile delivery and provide feedback and find improvements. Retrospectives are sometimes overlooked for their value that they provide to a team. Usually for the following reasons: 1. They are not run effectively and efficiently 2. Actions are not taken 3. Action are not actioned 4. Feedback is not captured The usual method of a retrospective is to get the team to all provide feedback on: What went well? What should we keep doing? What didn’t go well? What should we stop doing? What are you confused about? One method that I usually use is the happy :) confused ? sad :( boards with post-it notes. 1. The scrum master will re-cap on some of the work in the last sprint along with any milestones or key meetings or showcases 2. The team will spend 10 – 15 minutes reflecting on this and write thei...

So we left off in the previous post on "How do we take estimates and turn them into a projected timeline?" Now that you have identified the total scope of a project and the estimated story points it’s now time to identify how long it will take your team to achieve the goal. We do this by using what is called velocity. This is a metric for work done, usually used for planning and measuring team performance. Usually product owners (PO) would like to see a total view of a project so even the blue sky scenarios and not just Minimum viable product (MVP) can be used in your estimates and timelines. There are a few methods to do this but recently I have been using the three round velocity estimation game and this is usually done with new teams. If you already have a well established team then you would apply your current average velocity. To do this have your story map in front of you and as a team get your product owner to ask for the commitments of each developer for the...

You would have seen my recent post on story mapping and bringing a project to life with UI, features and user stories. Now comes the fun part, estimates and how to use these in an agile process. Understanding the size of a piece of work is always important to people, some more then others, especially when there is cost involved. The idea of estimates is to gain this understanding and provide guidelines to your stakeholders. Some questions you are trying to answer here are: "How long will this take us?" "How much will this cost us?" One way that works for me is carrying out estimates for an MVP, which is a subset of user stories that are identified as a minimum delivery for added value. Using the story map from an earlier post we use a tool called estimation poker. How to play estimation poker Prerequisites: Run through each story so the team understand the end-to-end Break any stories down if something is to large Agree on a Definition of Do...