Skip to content
@jefkalil

@jefkalil

SaaS Product & AEC-Tech leader with 20+ years in user-centric, data-driven innovation, transforming products for growth and impact.
  • Home
  • About Me
  • Product Cases
    • Content Experience Product X – Unleashing the Potential of Content
    • Engagement Product X – Inspiring change in Medical and Nursing Education
  • AEC Projects
  • Custom GPTs
  • Cookie Policy
  • Privacy Policy
  • By - jef
  • Posted on December 16, 2016December 16, 2016
  • Posted in Product Management, Sprint

Transition to agile: pre-sprint planning

So, I’ve spent my last days sending out calendar holds, mini 1-on-1s, and completing rough documents that begin scope out the vision and “really big” stories for the project. Since we are approaching the holiday season most of the next weeks will be spent planning and setting up a workspace so we are ready for Sprint 1.

Digital handwriting w/ iPencil
My digital writing is no more legible than pen and paper. 😉

The planning call today covered some basics that we’ll need in this project. As previously stated we won’t run this as a traditional software development sprint, but rather apply agile to an innovation product management sprint, with a cross-function team of 4 core members. I’ve created the checklist below that should help you get things running if you’re new to this process.

  • Define each work streams and verify an owner of eacH – Ours are defined as technology/design, content development and production, business, and marketing
  • Setup pep-talks with the owners, mini 1-on-1s
  • Define a commitment goal for the core group – We won’t be looking this group in a rooo for 2 week sprints so we agreed that a commitment for 35-40% of each persons total time will be our sweet spot. (There is no sweet spot in agile. The goal is for the team to be motivated and be able to deliver in short chunks.)
  • Set a start date and an end date for the first release – we’ve pick a national event in March where key influencers will be. Goal is to create awareness for the pilot project and have influencers recommend it to our target users.
  • Setup baseline configuration – we will be use JIRA
  • Import rough (really big)  stories to start building a backlog, pick a few that may be relevant for the first sprint and analyze these to ensure we have what is needed to put them into the first sprint – budgets, specification, business support, etc
  • Decide how to size stories – points or hours – being a cross-functional team with non-software expertise we’ve chosen to use hours rather than story points.

I hope this helps give some guidance with the pre-sprint planning process. I’m not brand new to agile, but adopting it as a new innovation tool for managing this project introduces some new challenage and hurdles. Feel free to ask me any questions along the way and follow me to stay updated.

So I’ll leave you with two last points that may help you until the next post:

  1. Always just focus on the current sprint – the next two weeks.
  2. Create stories that can be completed to help the team perform at their best.

you may want to read the previous post A Transition to Agile

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Tumblr (Opens in new window)
  • Click to share on Pinterest (Opens in new window)
  • Click to email a link to a friend (Opens in new window)
Tags :AgileConfluenceJIRAPre-sprint planning
Share this
Previous Article
Using the Lean Canvas to Track the Product Hypothesis
Next Article
The Product Scorecard – measure it, so you can manage it

Follow Me

  • LinkedIn
  • Twitter
Copyright © 2023 @jefkalil. All Right Reserved.
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}
 

Loading Comments...
 

You must be logged in to post a comment.