DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Security Challenges for Microservice Applications in Multi-Cloud Environments
  • Web Development Checklist
  • Transactional Outbox Patterns Step by Step With Spring and Kotlin

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Security Challenges for Microservice Applications in Multi-Cloud Environments
  • Web Development Checklist
  • Transactional Outbox Patterns Step by Step With Spring and Kotlin
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. How to Use Continuous Planning

How to Use Continuous Planning

A follow up to "Reasons for Continuous Planning," focusing on the implementation of continuous planning and an example.

Johanna Rothman user avatar by
Johanna Rothman
·
Aug. 18, 15 · Opinion
Like (1)
Save
Tweet
Share
4.34K Views

Join the DZone community and get the full member experience.

Join For Free

If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas.

You have a couple of preconditions:

  • The teams get to done on features often. I like small stories that the team can finish in a day or so.
  • The teams continuously integrate their features.

Frequent features with continuous integration creates an environment in which you know that you have the least amount of work in progress (WIP). Your program also has a steady stream of features flowing into the code base. That means you can make decisions more often about what the teams can work on next.

Now, let’s assume you have small stories. If you can’t imagine how to make a small story, here is an example I used last week that helped someone envision what a small story was:

Imagine you want a feature set called “secure login” for your product. You might have stories in this order:

  1. A person who is already registered can login with their user id and password. For this, you only need to have a flat file and a not-too-bright parser—maybe even just a lookup in the flat file. You don’t need too many cases in the flat file. You might only have two or three. Yes, this is a minimal story that allows you to write automated tests to verify that it works even when you refactor.
  2. A person who is not yet registered can create a new id and password.
  3. After the person creates a new id and password, that person can log in. You might think of the database schema now. You might not want the entire schema yet. You might want to wait until you see all the negative stories/features. (I’m still thinking flat file here.)
  4. Now, you might add the “parse-all-possible-names” for login. You would refactor Story #2 to use a parser, not copy names and emails into a flat file. You know enough now about what the inputs to your database are, so you can implement the parser.
  5. You want to check for people that you don’t want to log in. These are three different small stories. You might need a spike to consider which stories you want to do when, or do some investigation.
    1. Are they from particular IP addresses (web) or physical locations?
    2. Do you need all users to follow a specific name format?
    3. Do you want to use a captcha (web) or some other robot-prevention device for login (three tries, etc.)?

Maybe you have more stories here. I am at the limit of what I know for secure login. Those of you who implement secure login might think I am past my limit.

These five plus stories are a feature set for secure login. You might not need more than stories 1, 2, and 3 the first time you touch this feature set. That’s fine. You have the other stories waiting in the product backlog.

If you are a product owner, you look at the relative value of each feature against each other feature. Maybe you need this team to do these three first stories and then start some revenue stories. Maybe the Accounting team needs help on their backlog, and this feature team can help. Maybe the core-of-the-product team needs help. If you have some kind of login, that’s good enough for now. Maybe it’s not good enough for an external release. It’s good enough for an internal release.

Your ability to change what feature teams do every so often is part of the value of agile and lean product ownership—which helps a program get to done faster.

You might have an initial one-quarter backlog that might look like this:

Example.AgileRoadmapOneQuarter








Start at the top and left.

You see the internal releases across the top. You see the feature sets across just under the internal releases. This part is still a wish list.

Under the feature sets are the actual stories in the details. Note how the POs can change what each team does, to create a working skeleton.

The details are in the stories at the bottom.

This is my picture.You might want something different from this.

The idea is to create a Minimum Viable Product for each demo and to continue to improve the walking skeleton as the project teams continue to create the product.

Because you have release criteria for the product as a whole, you can ask as the teams demo, “What do we have to do to accomplish our release criteria?” That question allows and helps you replan for the next iteration (or set of stories in the kanban). Teams can see interdependencies because their stories are small. They can ask each other, “Hey can you do the file transfer first, before you start to work on the Engine?”

The teams work with their product owners. The product owners (product owner team) work together to develop and replan the next iteration’s plan which leads to replanning the quarter’s plan. You have continuous planning.

You don’t need a big meeting. The feature team small-world networks help the teams see what they need, in the small. The product owner team small-world network helps the product owners see what they need for the product over the short-term and the slightly longer term. The product manager can meet with the product owner team at least once a quarter to revise the big picture product roadmap.

You can do this if the teams have small stories, if they pay attention to technical excellence and use continuous integration.

In a program, you want smallness to go big. Small stories lead to more frequent internal releases (every day is great, at least once a month). More frequent internal releases lead to everyone seeing progress, which helps people accomplish their work.

You don’t need a big planning meeting. You do need product owners who understand the product and work with the teams all the time.

The next post will be about whether you want resilience or prediction in your project/program. Later :)

agile planning

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Security Challenges for Microservice Applications in Multi-Cloud Environments
  • Web Development Checklist
  • Transactional Outbox Patterns Step by Step With Spring and Kotlin

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: