Newbie ScrumMaster

The first question was not very clear, I should fix all bugs that appear in addition to complete the tasks of the new version.

Hi Cleber,

Correct of if I’m wrong, but it seems like your company is relatively new with scrum?

If yes, it would be a good idea (for your company) to attend some agile scrum training.

Do you have a (delegate) product owner (PO) on the project? In other words, someone with the authority and/or vision whom can point the development team into the right direction? If not, make sure you get one!

1. It should be fine to deliver a version of the product on a fix date. Just make sure your project is not tied up in a fix scope/date situation.
Try to work with the PO in setting up a product backlog with items and priorities it in terms of business value. If the bugs are that important, I expect the PO to place these items all the way up.

2. Yes, and don’t forgot the refinement sessions.

3. Would be good for your organisation (and you) to attend the scrum training. Can imagine that it’s extremely challenging to facilitate a scrum team in an organisation that is new with scrum.

Cheers, Chee-Hong

In my opinion not a good solution will be to implement "half" of Scrum.
As you have a lots of bug fixing PO can e.g. add a US to the backlog for the work related with the bugs.

Scrum is a framework so you should go after all the good solutions and show how much they are important to together to achive you goals and deliver the best code quality.

Half of scrum is not scrum unfortunately.
Simply said, scrum can be seen as a set of rules. These rules are the foundation of the scrum framework/tool/methodology. (give it a name)

> The company must deliver a version of their product (software) on a
> date already fixed. This version can not delay. The point is that this
> sprint in specific I should meet all the demands of the bug fix that
> arise from the current version. Do you have any tips on how I proceed
> to try to succeed?

Any defects that do not relate to work currently in progress should be triaged onto the Product Backlog. In other words, defects relating to work that was delivered in previous sprints should be handled as new Product Backlog Items. It's up to the Product Owner to decide how they should be prioritized in terms of Product Backlog order.

During Sprint Planning, the Development Team will induct as many prioritized PBI's (including defects) into their Sprint Backlog as they believe they can handle in the Sprint time-box. Regardless of their nature, these items should all contribute to a potentially releasable increment that meets a valuable Sprint Goal.

Thanks for the tips .

Chee - Hong Hsia , SCRUM is new to the company . They used "half " of Scrum as stated above . In a recent meeting between the PO and the team , which I was a rookie , there was a discussion about why the deadlines were not met. As it was my first meeting I was just listening . Then when everyone had spoken , I I understood that much of the failure of their methodology was not having a problem-solver , in which case it would be a SCRUM Master , the team lost a lot of time getting in touch with customers and resolving other internal issues that were not code. The members of the team did not know the tasks that each was working . The Sprint was created only by the OP , there were daily meetings from time to time . In short , it was a mess, it was not SCRUM . That said . I proposed using SCRUM with all rites and roles required . So the director gave me the responsibility to implement SCRUM correctly. Said he would do a test with the methodology in the next sprint version . And the company should deliver all items that version already planned plus fix all the bugs that arise . The date for the submission of this version had already been established with clients , and they would evaluate whether the result was better than before

Ian Mitchell,

I understood what you said, however, the OP said specifically that sprint, bugs should be fixed along with the development of the sprint items because the previous deadlines were not met customers were very upset, so this version should not delay. It is really a problem on my hands. And the success of the sprint could mean the continuation of Scrum in the enterprise. And it will be good for me too.

I learned Scrum through reading books and has worked in another organization that used Scrum correctly as part of the development team.

Posted By Cleber Oliveira on 07 Apr 2014 09:50 AM
the OP said specifically that sprint, bugs should be fixed along with the development of the sprint items because the previous deadlines were not met customers were very upset, so this version should not delay.

If deadlines are not achievable, and you need a new tool to make them achievable, Scrum is not the right tool (and probably no tool is). Scrum doesn't create more time for developers magically.
The Product Owner cannot say that you have to fix the bugs along with the sprint items. Instead, he brings all Product Backlog Items (including bugs) in an order, and the development team decides which items to pull into the sprint according to their order, size, technical or business coherence etc.
This will sound crazy to the Product Owner, but it is how it works in Scrum.
Long term, he will learn not to make impossible promises to the stakeholders.

there was a discussion about why the deadlines were not met. As it was my first meeting I was just listening . Then when everyone had spoken , I I understood that much of the failure of their methodology was not having a problem-solver

Sounds like you guys has already started a retrospective to tackle the “why deadline hasn’t been met” issue? Just make sure that the team has done the proper root cause analysis in identifying the true problems. So for the next sprint, let’s see if it has improved or not.

in which case it would be a SCRUM Master , the team lost a lot of time getting in touch with customers and resolving other internal issues that were not code.

It could be the scrum master. In reality the scrum master isn’t always the one that will actually solves the problems/impediments. The scrum master can also delegate it towards a team member. Important is that impediments get solved and that ownership belongs to the scrum master. But yeah, the more impediments the scrum master can solve, the more focus the team can be.

The members of the team did not know the tasks that each was working. The Sprint was created only by the OP , there were daily meetings from time to time .

Try to do the daily stand-up consistently! In other words, every day, same place, same time.
It’s good to set up some ground rules (with the team) before you continue.

Goodluck with implementing scrum!

>... the OP said specifically that sprint, bugs should be fixed along with the development
> of the sprint items because the previous deadlines were not met customers were very
> upset, so this version should not delay. It is really a problem on my hands.

It's more of a problem for the PO. The PO needs to prioritize the Product Backlog and also to ensure that he or she releases work to the customer that is of acceptable quality. Your problem as Scrum Master is to ensure that that the Development Team have Sprint Goals and Sprint Backlogs that are achievable for them, that they can go about their work without impediment, and that a Definition of Done is applied which everyone in the Scrum Team (including the PO) are in a position to observe.

At a wider level, your problem is one of coaching the organization to apply Scrum, including the roles and responsibilities that are involved. That's a big part of being a Scrum Master too.