Are you an analyst sharing our quest for continuous improving our agile methods? Have you found that look ahead modeling is harder that it seems, when trying to deliver the right info at the right moment, not forgetting to embrace change? Than read on!
Nowadays I’m expanding my agile journey as a Analyst Coach at a Disciplined Agile Team. Combined with the research of my master thesis on Agility at Scale, I found that many teams struggle with the lack of prescriptive methods while becoming agile. There is no silver bullet: “If you do it this way lads & lassies, all will be just fine!”, although everybody seems to be looking for it.
One of those topics that we as analysts (business and functional), are challenged with is the look ahead modeling, during the execution of an agile project. Our quest moved from pushing a complete solid consistent analysis to the dev-team towards being responsive to the dev-team needs and delivering just enough analysis, just in time, whilst embracing the ever changing needs of our business. It is a constant balance on the thin cord of assuring software quality and embracing change.
Self-organizing as we are, we found the need for a bit of in-team governance to assure that everything was ready on time, and we did just enough, and that’s how we invented our ‘Ultimate Look Ahead Modeling Checklist‘: a list of topics that we do each sprint to assure that our analysts do just enough (not too much), and just in time (not too late). Important to say is that I don’t pretend this list to be used as a prescriptive model by anyone everywhere, but sharing is caring, and therefore we hope that this list might inspire other teams to help them in their quest to continuous improvement. You’ll also see that we have chosen to use some relevant analysis methods, and yes, some documentation, as we value working software over documentation, we still see the need to document the basics for quality assurance.
Our agile context
We are doing SCRUM, with sprints of 2 weeks, as we found that it lifted our velocity to the maximum. Before we started coding we did an inception phase, where we iteratively clarified our scope. Now during execution we further clarify the scope as we go along, allowing change, via our look ahead modeling process. We are using User Stories and Acceptance Criteria, combined with some Mockups as Business Analysts, and Domain Models (via Domain Driven Design principles), Resource Models (to support our RESTfull architecture) and Navigation Diagrams as functional analysts.
Also known as the ‘Pre-Sprint Planning’. A short meeting between the Product Owner, Business Analyst, Functional Analyst and Dev Lead to discuss the potential scope of the upcoming sprint.
- Check the high-level capacity of the DEV-team in Sprint X+1
- Identify potential scope of Sprint X+1
- Prioritize the User Stories
- Send the list with potential USies to the PM, Dev Lead, PO, FA & BA
Look Ahead Modeling – Business Analyst
The business analyst, will further clarify the USies for the upcoming sprint with the Product Owner
- Create a new ANA sprint backlog for Sprint X+1
- Copy the relevant USies from the Product Backlog to the ANA Sprint X+1 Backlog
- Check the Acceptance Criteria of the ANA Sprint X+1 Backlog for that sprint, to see if all acceptance criteria are still up to date
- Create some mockups when necessary to clarify the scope in more detail
- Discuss in detail these USies with the Functional Analyst
Look Ahead Modeling – Functional Analyst
The functional analyst will document the USies in scope in the functional analysis, preparing everything for the devteam.
- Discuss in detail the USies in scope with the Product Owner/Business Analyst
- Refine the acceptance criteria and clarify unclear scope with the Product Owner/Business Analyst
- Update the Domain Model
- Update the Resource specification
- Update the GUI Navigation Diagram
- Create the Sprint X+1 Documentation Website (we use Enterprise Architect as modeling tool, and it is easy to create a website containing the relevant topics for the dev-team).
The dev lead checks with the system testers which bugs are still open and prioritizes them, to identify further which bugs will be taken into the next sprint.
Sprintplanning – Product Owner Presentation
- The Product Owner presents the USies in scope with their acceptance criteria, when needed also show a mockup to clarify in more detail
- The Business Analyst documents changes due to the discussion with the devteam
Sprintplanning – Devteam Planning
- The DEV-Team defines sprint backlog with user stories and tasks
- The functional analyst documents in detail which USies or parts from USies are in scope from the ANA Sprint Backlog and copies the relevant acceptance criteria to the USies in the DEV Sprint Backlog
Testing After Demo
After the Demo of Sprint X, the system tester can test the test cases that were created during that sprint.
- Run the system tests for that sprint
- For each failed test case, define whether it is a product issue or a test failure (= test case not able to be tested as a whole, improve the test case!)
- For the product issues, discuss them with the Dev Lead what the issues were, and if a bug needs to be created
- Create the necessary bugs and notify the DEV Lead, so that he/she can pick it up during the next sprint planning.
During the sprint, the System Testers takes the DEV USies and creates relevant test cases for the defined acceptance criteria that will be tested in the next sprint.
- Create new Test Plan for the Sprint in MS Test Manager
- Copy the relevant Test Cases from previous sprints to be tested in regression to the new test plan
- Create a new suite for the test cases of that sprint
- Create the test cases for each USie in the DEV Sprint Backlog
I hope this checklist might inspire other agile teams, but in the end it is all about doing just enough, just-in-time.