Do you find your spring planning meetings are well organised? With all the excellent progress we’ve made it’s surprising that we haven’t been able to easily come up with a plan for the next sprint.
Here are some concerns that i’d like to raise that might illustrate why we are having this problem.
- our sprint planning meetings lack joy.
- ongoing team changes.
- ambiguous team structure.
- a lack of detailed knowledge of the current excellent work that has been done.
- team size too large.
- a lot of our design work goes beyond the immediate sprint acceptance criteria.
- a top down approach using a conceptual design isn’t helping us build from the implementation up.
- sprints stories revolve around the needs of our technology stack rather than the needs of the business.
Here’s a planning solution for our next sprint
Let’s see if there’s anything in here we can use…?
Here’s an achievable product backlog with real world stories and actionable tasks for the next 2 weeks.
This will most likely involve intense collaboration and compromise, which is great!
|1.||**As a 3rd party developer I want to review the published RESTful web api contract.**|
|define rest maturity.|
|define rest state transfer style.|
|define rest domain style.|
|define rest application flow.|
|define rest base format and standard attributes.|
|update automated tests.|
|update reference implementation.|
|update help documentation.|
|update cms integration.|
|2.||**As a client I want to submit an individual.**|
|define model A.|
|define model B.|
|define model C.|
|create sql scripts and test data.|
|add business rule for locations.|
|add business rule for device.|
|add format validation.|
|incorporate format validation into outcomes.|
|3.||**As a client I want to update an individual’s details.**|
|update individual model.|
|create SQL scripts and test data.|
|create test data|
|implement business rules.|
|add format validation.|
We can build on our success
Each one of us can start by picking a single one of these tasks right now.
There is cross over and discussion required. We can work together, share knowledge. With this small groups can meet and resolve issues.
This approach positively reflects the awesome progress we’ve made so far!
We need some time to close off the outstanding tasks from last sprint too!
The following concerns should be taken into account when estimating the effort involved in completing a task and closing a story.
|Refactor||For all development tasks there is an expected amount of refactoring involved. This involves a high level of analysis and peer review.|
|Test||For each story there must be a new set of automated tests.|
|Document||For each story there should be a business friendly page that documents how the story has been implemented listing major design compromises and concerns.|
|Review||Each story must have a code review before it can be closed.|
Each story has these implicit activities that span across every task in a given story. For every task we should be sharing contributing effort to all of these activities.