2 min read

Should Stories & Bugs Follow Different Workflows?

By Joseph Lane on Mar 31, 2021 10:07:00 AM

Blogpost-display-image_Should stories and bugs follow different workflows-The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.

For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.  Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.

The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.

Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.

I hope this explanation helps you avoid unnecessary workflows!

Topics: blog best-practices bugs kanban scrum workflows software-development coding
5 min read

Common Agile Myths: Everything's Made Up and the Points Don't Matter

By Amanda Babb on Aug 14, 2020 4:00:00 PM

2020 Blogposts_Everythings Made Up and the Points Dont Matter- Common Agile Myths

Type "Agile myths" in your favorite search engine and you'll be amazed at the plethora of results. Especially those that say, "Top myths busted!" While I consider myself an Agile evangelist, I'd like to take a moment to discuss the harsh reality that many organizations face day-to-day. Agile is not a new concept, but the term is. The Agile Manifesto codified the term and working agreements in 2001, but I (and other evangelists) argue that it existed way before the term was formalized then attached strictly to software development. 

Iterative Development of Complex Systems

"I felt exactly how you would feel if you were getting ready to launch and knew you were sitting on top of 2 million parts — all built by the lowest bidder on a government contract." - attributed to astronaut and U.S. Senator John Glenn 

There were three Apollo missions before a person was ever placed in a rocket to (eventually) go to the moon. February through August of 1966 saw rocket, heat shield, and in-orbit fuel performance tests before a person set foot in the capsules. After the tragedy of Apollo 1, three more unmanned missions were flown before NASA decided to try again. It took an additional four Apollo missions before Apollo 11, and the iconic first step happened in 1969. That giant leap didn't happen with Big Up Front Requirements. It happened with teams of teams working together, iterating, retrospecting, and making adjustments. Isn't that Agile and moreover Agile at scale? 

How many other times in history did we as humans nail something the first time? The Wright Brothers didn't just magically produce an airplane that sustained controlled flight in 1903. Carl Faberge didn't create imperial eggs immediately upon his return to St. Petersburg in 1872. It's not called WD-1, it's called WD-40. Agile is how we've developed some of our greatest inventions, art, and human achievements. 

Scrum versus Kanban Agile

Let's take a step back and look at the two most popular frameworks of Agile: Scrum and Kanban. Instead of boring you with the typical definitions, instead, let's look at why teams and organizations think they choose one over the other. 

Scrum

"I am guaranteed to release product to my customers every two weeks."

Potentially shippable product does not mean it's in the hands of the customers. It means it meets the team's definition of done. It may have to be deployed into an integration or stage environment before production for further integration and testing before being released. 

"We don't have to estimate capacity, we just estimate the work."

Scrum (and Agile in general) is about predictability. If you delivered an amount of work this sprint, you should be able to deliver a similar amount for "the next sprint. If your velocity makes wild swings from sprint to sprint, there's a larger problem. A good team plans their sprint delivery based on their past performance. Which leads to another one...

"There is no long-term planning, just short-term execution."

Scrum is where long-term product planning meets short-term execution. Products and product features are extremely long-lived if they are the right things. No one wants to spend time and money on things that customers won't use or don't work.  

Kanban

"We do Kanban because Scrum takes too much time."

Kanban was born from lean manufacturing. There is always a daily standup at the beginning of the shift. In best-in-class manufacturing, there is also a weekly meeting for metrics and a monthly safety meeting. In order to be successful, your Kanban teams should be taking almost the same amount of time!

"Kanban isn't planned or managed. Just executed."

The Kanban backlog is just as refined as a Scrum backlog. Based on classes of service, the team plans their work each day and throughout the week. For example, work in the "standard" class of service is defined as start to finish in the calendar week. 

"Our team isn't a software development team."

I waver on this one. Unless you are pure customer service (think call center), you likely have larger projects you're trying to complete. 

So what?

Given all of the above, it's safe to say there is definitely no single right way to be Agile (although there are LOTs of wrong ways!). As an organization, there will likely be growing pains while you try to figure out how teams work best. 

Agile is not a thing you do. It's not a software development framework. It's not a 40-hour skill. Or a two-week sprint skill. Or even a Program Increment skill. It's a mindset...nay...I would argue it's a lifestyle. Agile is all around us if you open yourself to it. 

 

Looking for more tips on how to be Agile? Check out Agile Batch Size: An Ode to Laundry or The ABC's of Agile. And if you want to know more about how to successfully implement Agile in your organization, reach out to us

Topics: scaled-agile enterprise kanban scrum agile
2 min read

Kanban vs. Scrum: Which One and Why?

By Suze Treacy on Jul 23, 2019 1:48:00 PM

Are you looking for ways to make your work more flexible and efficient, but feeling late to the Agile transformation party? Well, fear not! It's OK to be fashionably late to this Agile shindig!

Out of the many Agile Development frameworks out there, Scrum and Kanban are arguably the best known - similarities include their focus on continual improvement, and minimizing waste; breaking down large pieces of work into manageable, bitesize chunks for efficient delivery. However, it's important to understand the differences when looking to choose which style of working is right for you and your team.

What is Kanban?

Kanban, a workflow visualization tool, was first developed in the 1940s by Taiichi Ohno, for Toyota. Faced with a lack of productivity compared to their American rivals, the aim was to find a way to optimize productivity alongside their cost-intensive inventory of raw materials. A continuously improving process, Kanban uses boards with team-determined limitations to limit WIP (work-in-progress), identify and eliminate bottlenecks quickly and improve efficiencies among the team. Formal training is not required for teams to get started in Kanban, and, given that Kanban boards are intended to be used by everyone on the project, there is less need for cross-functional team members - it's easy to get started with Kanban quickly!

What is Scrum?

Although the history of Scrum is not without its controversies, it is widely understood that Scrum was developed in the 90s by Jeff Sutherland and Ken Schwaber, to present at the OOPSLA conference in Austin, Texas. Sutherland and Schwaber borrowed the term "Scrum" from Takeuchi/Nonaka's paper ‘The New New Product Development Game’ - comparing a team sport like rugby with success in the 'game' of product development. Scrum is far more structured than Kanban - with commitments to short iterations of work, team members have designated roles and responsibilities (product owner, scrum master, team members), with clear priorities identified by the product owner. High visibility engages and increases team accountability, while daily meetings enable blockers to be identified and dealt with quickly; sprints (and potentially shippable increments) are generally being delivered every 2 weeks. It is this lithe process which allows Scrum teams to quickly adapt to change, maintaining and building upon team efficiencies in future sprints.

Which method is right for me?

The long and short answer is that there's no right answer for everyone. The best thing you can do for your team is to learn more about each framework and give them both a shot. It isn't always easy to break old habits; the road to a true Agile transformation can be long and daunting - we'd love to help you get on your way and show you how Jira can enable you to optimize your Agile processes; email us at contact@praecipio.com for more information. In the meantime, learn how Praecipio Consulting helps our clients conquer the Agile transformation using Atlassian tools, so they can drive business results, and innovate.

Topics: blog scaled-agile kanban scrum
2 min read

Here Comes the Product Owner: Wedding Planning with Atlassian

By Praecipio Consulting on Feb 13, 2015 11:00:00 AM

When Praecipio Consulting Senior Solutions Architect and Certified Scrum Master Amanda Babb got engaged over the new year, her first thought (after "Yes, I'll marry you" of course) was that this was an affair for the Atlassian tool set. With family members on both coasts and Amanda and her fiancé residing in Texas, she knew Atlassian would be the trick to best practices in MDLC (Matrimony Development Life Cycle). "There was never a question." says Babb. "From the moment we got engaged, I got a Cloud instance." Establishing a Kanban board that will take Amanda and her family from gathering information about venues to the nitty-gritty tasks like purchasing the cake slicer, this Scrum Master feels confident in an on-time, on-budget release of an October 2015 wedding.

 

Amanda Babb, Sr. Solutions Architect & Bride-to-Be

With Jira, Jira Agile, Confluence, and Team Calendars in her arsenal of planning tools, Amanda began on-boarding her family, including Project Stakeholders, Mom and Dad. After spending time showing her parents how to use the tools, they were able to begin collaborating and creating tasks. "The first thing my dad did was create a bug in Jira called Fat Elvis or Skinny Elvis and how many," Babb happily shares, noting that they have ultimately decided not to have their wedding officiated by an Elvis of any kind. Aside from fun with naming conventions, her family has enjoyed the ease with which they can view and add to wedding details, as often these large-scale affairs get bogged down with endless email chains, binders and internet bookmarking. With Atlassian, Amanda is able to share everything from a budget table for tracking deposits to multiple wedding registries and even bridesmaid dresses. Like most Scrum Masters, this bride's biggest "blocker" is adoption, often having to remind her family that, "it's in Confluence!"

So what does Babb's fiancé Doug think about his bride-to-be's planning with Atlassian? "He likes that it's streamlined communications." Babb reports. "Since we have opposite work schedules, it makes it easy for him to respond quickly. All I have to do is mention him in a comment!" Once Amanda and Doug have become husband and wife, their Atlassian instances will continue to play a role in their marriage. Babb intends to continue using the products for household projects, increasing transparency and communication between the couple leveraging a shared knowledge base. 

On this Valentine's Day, Praecipio Consulting wishes Amanda and Doug (along with all the other Atlassian lovers out there) all the best! May your collaborations be harmonious, your issues quickly resolved and each of your iterations better than the last.

 

HAPPY VALENTINE'S DAY!

Love,

Praecipio Consulting

Topics: jira atlassian blog scaled-agile best-practices calendars confluence kanban jira-software
3 min read

GreenHopper 5.8 Now Available: Rapid Board for Kanban

By Praecipio Consulting on Oct 19, 2011 11:00:00 AM

GreenHopper 5.8 is now available, delivering a huge win for everyone: the new Rapid Board.

A major innovation for GreenHopper, the Rapid Board’s a flexible new board for managing and reporting on work in progress. The Rapid Board also provides multiple project support, which alone satisfies a whopping 255 votes - the most requested feature in GreenHopper’s history!

What’s the Rapid Board?

The Rapid Board provides a new way to view issues in GreenHopper by creating Rapid Views.  Creating new Rapid Views is simple:

  1. Save a Jira search
  2. Layout status columns
  3. Set Swimlanes & Quick Filters

This brilliant simplicity calls upon the most powerful search in issue tracking: Jira’s Query Language (JQL). The power of Jira’s advanced search is behind every aspect of the new GreenHopper Rapid Board. The Rapid View, horizontal Swimlanes, and button Quick Filters are all based on JQL search parameters:

This means large teams can collaborate on a single Rapid View, while individuals can use Swimlanes and Quick Filters to see just the issues that matter most to them.

Work Smarter

The new Rapid Board has several smart features in the background. Atlassian’s focused this first release of the Rapid Board on Kanban-specific features, and will continue to work on features for Scrum and all types agile teams as the Rapid Board evolves.

  • Kanban presets: an Expedite swimlane, 3 Quick Filters, default columns (To Do, In Progress, Done), and issues ordered by Global Rank.
  • Permanent links mean ‘what you see is what they get’ when emailing or IM’ing URLs – and include not only you exact view, but also the selected issue or report.
  • Keyboard shortcuts let you perform any issue operation, including selecting an issue and ranking actions, without touching a mouse.
  • Drop zones indicate the available transitions when moving an issue.
  • Column headers stay with the board when scrolling down the page, so there’s no need to scroll back up to find information or take action. 
  • Issue cards have gotten an uplift: avatars show up indicating the card assignee, and the number of days in current status are indicated by dots across the card.
  • Columns can have both a min and a max constraint: limit the amount of work in progress (WIP) for each column to keep the team moving things along.

Keep Issues Moving Across the Board

We’ve added a new Control Chart to show the mean cycle time and trends. Control Charts, along with the “time in status” dots across issue cards, help teams spot outliers and understand which issues spend a long time in flight. 

The Rapid Board views are also available as gadgets, so it’s easy to display this information on a Jira dashboard or a Confluence page. GreenHopper 5.8 is a huge step forward in understanding your teams work andcommunicating priorities and progress to the rest of the org. If you aren’t yet using GreenHopper or you want to see the new features in action, check out the short overview video.

Upgrade Jira & GreenHopper

GreenHopper 5.8 is available today, you’ll just need to upgrade to Jira 4.4.3 to take advantage of all the great new stuff! After you upgrade Jira, search your Jira plugin manager for the latest GreenHopper release.

Topics: jira atlassian blog scaled-agile kanban upgrade control greenhopper jql rapid-board

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us